[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140716175312.GM17402@brightrain.aerifal.cx>
Date: Wed, 16 Jul 2014 13:53:12 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com
Subject: Re: issetugid?
On Wed, Jul 16, 2014 at 09:31:41AM +0200, Florian Weimer wrote:
> On 07/16/2014 06:07 AM, Rich Felker wrote:
> >In the interest of fostering cooperation rather than fragmentation
> >when adding new APIs like this, I'd like to know if the glibc side has
> >any interest in adding this function, or any objections to the way it
> >works on BSDs and what's been proposed for inclusion in musl (see the
> >link above).
>
> glibc already offers getauxval(AT_SECURE) and
> prctl(PR_GET_DUMPABLE), so I'm not sure if another interface is
> needed.
This is a very good point. The LibreSSL folks are claiming that
getauxval(AT_SECURE) is not safe due to the lack of any way to detect
bug #15846 at runtime (and trying to use a strverscmp against the
glibc version string as a way to know if the bug is present...).
However, I think they're wrong because AT_SECURE is always included in
the aux vector for all kernels glibc supports; ENOENT cannot happen.
And if there were a way to suppress AT_SECURE, it would affect
LD_PRELOAD etc. anyway and thus already be a vulnerability independent
of getauxval's reporting of errors.
I don't think prctl(PR_GET_DUMPABLE) is relevant or useful for this
since it would have to be tested at startup before any application
code runs in order to reflect the AT_SECURE status.
> On Linux, the function name issetugid is misleading because you
> generally want to include transitions caused by Linux Security
> Modules which do not alter UID or GID as well.
I agree that the name was poorly chosen, but I'm not sure that it's
worth inventing yet another name rather than just documenting the
discrepency.
> What's worse, the Solaris and FreeBSD versions of issetugid are
> different, so we'd have to pick one behavior and be incompatible
> with the other.
Could you explain how they differ? I'm reading the Solaris
documentation here:
http://docs.oracle.com/cd/E23823_01/html/816-5167/issetugid-2.html
and it appears to match the semantics that were proposed for addition
to musl.
Based on your comments, I agree that this interface is non-essential,
but I still think it might be nice to have. While on glibc it's
probably equivalent to getauxval(AT_SECURE), musl partially (with
limited functionality) supports 2.4 kernels, and other systems may not
even provide getauxval (whose interface is closer to the low-level
internals rather than the outward semantics the application should
care about) so I think using something like issetugid() is a cleaner
approach for portable application code.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
