Date: Mon, 1 Oct 2012 17:11:34 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-current@freebsd.org Subject: Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries) Message-ID: <CAFHCsPX5vsNkBMNtVneTubdxcEKVi00qCVwLpR2q_EK8EdTKSQ@mail.gmail.com> In-Reply-To: <201209071540.43013.jhb@freebsd.org> References: <CAFHCsPX6HrCXHA%2BS31Dz9QP8eiwbo21Vzju4K4paohciu2vPTw@mail.gmail.com> <201209071405.28831.jhb@freebsd.org> <20120907184120.GD33100@deviant.kiev.zoral.com.ua> <201209071540.43013.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 7, 2012 at 9:40 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Friday, September 07, 2012 2:41:20 pm Konstantin Belousov wrote:
>> > I think these would be rare? There's no good reason for anything to write to
>> > a shared library that I can think of. install(1) does an atomic rename to 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.
>
> Yeah, that's fair. Also, I hunted around to find the description of MAP_TEXT
> in Solaris 11. It seems from reading that that MAP_TEXT on Solaris isn't used
> to prevent writes ala VV_TEXT. Instead, it is used as a hint that is
> apparently used to use superpages for text.
>
> --
> John Baldwin
Hi,
I'd like to finish this thread somehow. For security sake, it looks
that bounding VV_TEXT with MAP_TEXT is not good idea. Now, I see only
two possibilities how to solve the shared libraries issue in general.
1. To have one more permission flag, first for files on which
VV_TEXT can be set and second for files on which VV_TEXT may not be
set.
2. To activate shared libraries in kernel.
The whole situation is following.
There are two basic kinds of binaries in system. The first ones only
need to be activated, the second ones need to be interpreted by an
interpreter which is activated already. While activation is a concern
of kernel and should be done in kernel, an interpretation is a concern
of an interpreter and as such is done in userland. Unfortunately, even
so different in nature, both share x+ permission and can't be
distinguished by it.
The shared libraries issue is that even they can be activated only,
they are interpreted by dynamic linker instead. As VV_TEXT is kernel
flag and can be set safely by kernel only, there is no way how to
protect them by the flag in this situation.
Svata
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPX5vsNkBMNtVneTubdxcEKVi00qCVwLpR2q_EK8EdTKSQ>