From owner-freebsd-current@FreeBSD.ORG Fri Sep 7 18:41:26 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA2901065673; Fri, 7 Sep 2012 18:41:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6AE7B8FC12; Fri, 7 Sep 2012 18:41:24 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q87IfWFr031493; Fri, 7 Sep 2012 21:41:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q87IfKKd072255; Fri, 7 Sep 2012 21:41:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q87IfKGd072254; Fri, 7 Sep 2012 21:41:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 7 Sep 2012 21:41:20 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120907184120.GD33100@deviant.kiev.zoral.com.ua> References: <201209071221.37409.jhb@freebsd.org> <20120907164218.GB33100@deviant.kiev.zoral.com.ua> <201209071405.28831.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3vZa96L4PgTIUS1Z" Content-Disposition: inline In-Reply-To: <201209071405.28831.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Svatopluk Kraus Subject: Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:41:26 -0000 --3vZa96L4PgTIUS1Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 07, 2012 at 02:05:28PM -0400, John Baldwin wrote: > On Friday, September 07, 2012 12:42:18 pm Konstantin Belousov wrote: > > On Fri, Sep 07, 2012 at 12:21:37PM -0400, John Baldwin wrote: > > > On Friday, September 07, 2012 12:02:08 pm Konstantin Belousov wrote: > > > > On Fri, Sep 07, 2012 at 05:12:37PM +0200, Svatopluk Kraus wrote: > > > > > On Tue, Sep 4, 2012 at 6:00 PM, John Baldwin wr= ote: > > > > > > On Tuesday, September 04, 2012 9:00:39 am Konstantin Belousov w= rote: > > > > > >> 2. I do not see what would prevent malicious local user from m= maping > > > > > >> arbitrary file readonly with MAP_TEXT, thus blocking any mo= difications > > > > > >> to the file. Note that this is not a problem for executable= s, because > > > > > >> kernel only sets VV_TEXT on executables if +x permission is= set and > > > > > >> file is valid binary which kernel is able to execute. > > > > > >> > > > > > >> E.g. you might block log writes with VV_TEXT, or other user= editing > > > > > >> session or whatever, having just read access to correspondi= ng files. > > > > > >> > > > > > >> Am I wrong ? > > > > > > > > > > > > Hmm, I do think 2) is a bit of a show-stopper. I do wonder why= one needs > > > > > > MAP_TEXT at all or if you could key this off of mmap() with PRO= T_EXEC? > > > > > > Do we require +x permissions for PROT_EXEC? No, it seems we on= ly require > > > > > > a file opened with FREAD. Hmm, perhaps rtld could open a separ= ate fd for > > > > > > PROT_EXEC mappings that used O_EXEC and mmap()'ing an O_EXEC fd= could enable > > > > > > VV_TEXT? That would require a file to have +x permisson for an= mmap() to > > > > > > enable VV_TEXT. It would also make MAP_TEXT unneeded. > > > > >=20 > > > > > It sounds good for me. I will try to patch it this way. However, = do > > > > > you think that will be acceptable to set +x permission to shared > > > > > libraries in general? > > >=20 > > > Shared libraries have +x by default already. You could make rtld fal= l back > > > to using the O_RDONLY fd if it can't open an O_EXEC fd in which case = you don't > > > get the VV_TEXT protection, but rtld would be backwards compatible. > > Where is it ? On fresh stable/9 machine, I have in /lib: > > -r--r--r-- 1 root wheel 7216 Dec 3 2011 libipx.so.5 > > -r--r--r-- 1 root wheel 19800 Jun 28 18:33 libjail.so.1 > > -r--r--r-- 1 root wheel 13752 Jun 28 18:33 libkiconv.so.4 > > ... >=20 > Hmm, I was looking in /usr/local/lib. It seems at least some ports do > install libraries with +x: >=20 > -rwxr-xr-x 1 root wheel 210494 Apr 8 2011 /usr/local/lib/libxml++-= 2.6.so.2 > -rwxr-xr-x 1 root wheel 1515416 Apr 8 2011 /usr/local/lib/libxml2.s= o.5 > -rwxr-xr-x 1 root wheel 44389 Apr 8 2011 /usr/local/lib/libxmlpar= se.so.1 > -rwxr-xr-x 1 root wheel 100672 Apr 8 2011 /usr/local/lib/libxmltok= .so.1 > -rwxr-xr-x 1 root wheel 266775 Apr 8 2011 /usr/local/lib/libxslt.s= o.2 > -rw-r--r-- 1 root wheel 764602 Apr 8 2011 /usr/local/lib/libxvidco= re.so.4 > -rwxr-xr-x 1 root wheel 53379 Apr 9 2011 /usr/local/lib/libzip.so= .1 >=20 > > > > Setting +x on shared libraries can be done. But setting VV_TEXT for > > > > such mappings is definitely non-standard behaviour, that could cause > > > > locking surprises for unaware system administrator. The issuw would= be > > > > very hard to diagnose. > > >=20 > > > I'm not sure it would be that obscure. It's the same as getting an e= rror that > > > a binary is busy. In that case you would resort to 'ps' to find the = offending > > > process. For this case (a shared library being busy), you could look= at the > > > output of 'procstat -af' to find which processes have executable mapp= ings of > > > the library. > >=20 > > I much more worry about rtld reporting 'shared library is busy'. It is = fine > > to not be able to write to mapped library. > >=20 > > Rtld errors are usually quite worrying for users, and they just do not > > understand them. >=20 > I think these would be rare? There's no good reason for anything to writ= e to > a shared library that I can think of. install(1) does an atomic rename t= o swap > in the new libraries already. After a second thought, I do not like your proposal as well. +x is set for shebang scripts, and allowing PROT_EXEC to set VV_TEXT for them means that such scripts are subject for write denial. --3vZa96L4PgTIUS1Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBKP9AACgkQC3+MBN1Mb4iagQCfWga+wKweqz6Q5mfvr9T2ZJyb eMoAoJQ5t9o0QLDd6mk64KcmXmoRlhy4 =Upo/ -----END PGP SIGNATURE----- --3vZa96L4PgTIUS1Z--