Date: Fri, 7 Sep 2012 21:41:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Svatopluk Kraus <onwahe@gmail.com> Subject: Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries) Message-ID: <20120907184120.GD33100@deviant.kiev.zoral.com.ua> In-Reply-To: <201209071405.28831.jhb@freebsd.org> References: <CAFHCsPX6HrCXHA%2BS31Dz9QP8eiwbo21Vzju4K4paohciu2vPTw@mail.gmail.com> <201209071221.37409.jhb@freebsd.org> <20120907164218.GB33100@deviant.kiev.zoral.com.ua> <201209071405.28831.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <jhb@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120907184120.GD33100>