From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0075.outbound.protection.outlook.com [104.47.0.75]) by dpdk.org (Postfix) with ESMTP id 0C3471B1C2 for ; Sun, 28 Jan 2018 12:47:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OZti1TShRiKzvsWmevzrgJKZhJK43a1W7tcMDuEBWac=; b=VbMfKBRPyVaZYKOS09x2+vzEr8BXDoOZv9uWAUk4xSpxEAqd/LBO130yTNONG3bZ5vQzjbbWP5YHL1eQZJfeyQNbpRBEwsNFS22rQBqgJclZh7IQOIFMiKmKdg551WuL4JUSPY7BuRi/qu6D7VRPiuJDZLUYNjRHrQ/mhwmUXeI= Received: from VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) by VI1PR05MB3453.eurprd05.prod.outlook.com (10.170.239.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Sun, 28 Jan 2018 11:46:59 +0000 Received: from VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::cd00:54ee:63a8:937c]) by VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::cd00:54ee:63a8:937c%13]) with mapi id 15.20.0444.016; Sun, 28 Jan 2018 11:46:59 +0000 From: Shahaf Shuler To: Marcelo Ricardo Leitner CC: Adrien Mazarguil , =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 2/4] net/mlx4: spawn rdma-core dependency plug-in Thread-Index: AQHTlrClOaHolUiUpE+XIRIveZP+6KOH0n0AgAEoM/CAACsxgIAAAqyg Date: Sun, 28 Jan 2018 11:46:59 +0000 Message-ID: References: <20180124223625.1928-1-adrien.mazarguil@6wind.com> <20180126141215.30395-1-adrien.mazarguil@6wind.com> <20180126141215.30395-3-adrien.mazarguil@6wind.com> <20180127150306.GH3494@localhost.localdomain> <20180128111749.GJ3494@localhost.localdomain> In-Reply-To: <20180128111749.GJ3494@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=shahafs@mellanox.com; x-originating-ip: [31.154.10.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB3453; 7:08Y+bUifT1SzVHhHMp/6W2K/aQzcpGz8d2tkltgL7dSlmof2fpXHf0wpN5cE0QwMKc4QHZvoEJhyQPczekVkvKAEZmoA1wMKAM2Q5kBLmWgIV8CtjfsF7ACjsAiOmIhcNuPkVlcVL5z/DwqC6mccIzeO4Yu98KaLcBHoI5OA4k1UxGn+4RcUYczo8ajkrakhpOl0tYxj1859NSkmJXlAGaFvs/shPg/mA5Q9X3w1AmNLW4G801OA0aec14jLqp2Q x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a55b724b-f0d3-420d-b8d9-08d56644d6d7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1PR05MB3453; x-ms-traffictypediagnostic: VI1PR05MB3453: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231101)(2400081)(944501161)(6055026)(6041288)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR05MB3453; BCL:0; PCL:0; RULEID:; SRVR:VI1PR05MB3453; x-forefront-prvs: 05669A7924 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39380400002)(396003)(376002)(39860400002)(199004)(189003)(305945005)(26005)(4326008)(81166006)(33656002)(6116002)(74316002)(7736002)(68736007)(186003)(25786009)(86362001)(59450400001)(8676002)(8936002)(6246003)(105586002)(229853002)(3846002)(99286004)(81156014)(7696005)(5660300001)(2906002)(6916009)(102836004)(66066001)(3660700001)(6436002)(54906003)(316002)(6506007)(76176011)(2900100001)(55016002)(9686003)(14454004)(106356001)(3280700002)(2950100002)(53936002)(97736004)(5250100002)(93886005)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB3453; H:VI1PR05MB3149.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zYlNKwx8F4IC5ByOBqEzmZJq1MUla6MXMNnMqxl9XAaobYIn2UuhkG6et3CjwTik6CkahwRL6aQKbMS2naJcdQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: a55b724b-f0d3-420d-b8d9-08d56644d6d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2018 11:46:59.0439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3453 Subject: Re: [dpdk-dev] [PATCH v2 2/4] net/mlx4: spawn rdma-core dependency plug-in X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 11:47:01 -0000 Sunday, January 28, 2018 1:18 PM, Marcelo Ricardo Leitner: > Hi Shahaf, >=20 > On Sun, Jan 28, 2018 at 09:04:36AM +0000, Shahaf Shuler wrote: > > Hi Marcelo, > > > > Saturday, January 27, 2018 5:03 PM, Marcelo Ricardo Leitner: > > > On Fri, Jan 26, 2018 at 03:19:00PM +0100, Adrien Mazarguil wrote: > > > ... > > > > +static int > > > > +mlx4_glue_init(void) > > > > +{ > > > > + char file[] =3D "/tmp/" MLX4_DRIVER_NAME "_XXXXXX"; > > > > + int fd =3D mkstemp(file); > > > ... > > > > + while (off !=3D mlx4_glue_lib_size) { > > > > + ssize_t ret; > > > > + > > > > + ret =3D write(fd, (const uint8_t *)mlx4_glue_lib + off, > > > > + mlx4_glue_lib_size - off); > > > > + if (ret =3D=3D -1) { > > > > + if (errno !=3D EINTR) { > > > > + rte_errno =3D errno; > > > > + goto glue_error; > > > > + } > > > > + ret =3D 0; > > > > + } > > > > + off +=3D ret; > > > > + } > > > > + close(fd); > > > > + fd =3D -1; > > > > + handle =3D dlopen(file, RTLD_LAZY); > > > > + unlink(file); > > > > > > This is a potential security issue. There are no guarantees that the > > > file > > > dlopen() will open is the file that was just written above. It could > > > have been changed by something else in between. > > > > Can you further explain what are the potential risks you want to > > protect from? >=20 > It is different in some aspects, >=20 > > I think this issue is not different from regular file protection under > > Linux. >=20 > in regular files we can ensure the right selinux contexts and permissions= are > set, which is not the case here. >=20 > /usr could be even mounted as R/O and files just loaded from there, while > with this approach you're allocating a new file on a temporary dir, which > potentially is using extra RAM memory to store it and then load it. So the issue is with the absolute path that contains the temporary file or = with the concept of embedding the library inside the DPDK binary?=20 >=20 > > > > If the DPDK process ran by root, then this approach is no less secure > > than the previous version of the patches that dlopen the > > /usr/lib/libibverbs.so and /usr/lib/libmlx5.so. root can also change > > them before the dlopen. >=20 > Maybe, and though that probably would leave traces in the system that tha= t > happened. >=20 > > In fact in terms of security, root user can intentionally damage the > > system in many other ways. >=20 > And a SELinux (mis)configuration could grant (unexpected) write access to > the file for some other, non-root, user. >=20 > > > > If the DPDK process ran by regular user X, then the only users that > > are allowed to modify the file created are user X and possibly root. > > Other users will not have write permission to it. > > if the same user change this temporary file, then it damages itself > > only, as the DPDK process run by it will probably won't lunch. >=20 > Let's work this from the other PoV: why embed the library in dpdk binary? > How is it any more stable than regular libraries? The main reason is not to force the DPDK user to install the DPDK. Using the approach suggest on this commit, DPDK user can just "make" DPDK a= nd that is it.=20 When the DPDK application starts, it spits a temporary file which happens t= o be usable with dlopen() and hard-linked with libibverbs and libmlx[45] an= d once loaded in memory, removes it from the file system. =20 dlopen the library itself will require the library to be in some well-known= location.=20 >=20 > If it's just to hide it from rpm dependency generator, there is probably = a > cleaner way to do it. For example, packaging the lib in a sub-package, or > maybe some more tricky rpm macro. Do you see it as a preferred solution ? Having the glue lib included in rpm= s and install it per demand in case the binary execution failed? >=20 > Marcelo