Date: Fri, 7 Sep 2012 19:42:18 +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: <20120907164218.GB33100@deviant.kiev.zoral.com.ua> In-Reply-To: <201209071221.37409.jhb@freebsd.org> References: <CAFHCsPX6HrCXHA%2BS31Dz9QP8eiwbo21Vzju4K4paohciu2vPTw@mail.gmail.com> <CAFHCsPXJc0w=6t5JwxD6kT=-pCuk6b9bruf=xA=rZXEfWOyrow@mail.gmail.com> <20120907160208.GZ33100@deviant.kiev.zoral.com.ua> <201209071221.37409.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--QW87tl/UEAXcMuUT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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> wrote: > > > > On Tuesday, September 04, 2012 9:00:39 am Konstantin Belousov wrote: > > > >> 2. I do not see what would prevent malicious local user from mmapi= ng > > > >> arbitrary file readonly with MAP_TEXT, thus blocking any modifi= cations > > > >> to the file. Note that this is not a problem for executables, b= ecause > > > >> 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 edi= ting > > > >> session or whatever, having just read access to corresponding f= iles. > > > >> > > > >> 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 PROT_EX= EC? > > > > Do we require +x permissions for PROT_EXEC? No, it seems we only r= equire > > > > a file opened with FREAD. Hmm, perhaps rtld could open a separate = fd for > > > > PROT_EXEC mappings that used O_EXEC and mmap()'ing an O_EXEC fd cou= ld enable > > > > VV_TEXT? That would require a file to have +x permisson for an mma= p() 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 fall ba= ck > 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 =2E.. >=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 error= that > a binary is busy. In that case you would resort to 'ps' to find the offe= nding > process. For this case (a shared library being busy), you could look at = the > output of 'procstat -af' to find which processes have executable mappings= of > the library. I much more worry about rtld reporting 'shared library is busy'. It is fine to not be able to write to mapped library. Rtld errors are usually quite worrying for users, and they just do not understand them. --QW87tl/UEAXcMuUT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBKI+oACgkQC3+MBN1Mb4gJewCfZxKgKh/5rW+MP6kY04yvRYtD 1bMAn27o3TOvKlOoOzKLt/SzsL9l0kXF =FjLa -----END PGP SIGNATURE----- --QW87tl/UEAXcMuUT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120907164218.GB33100>