Re: issetugid?

Re: issetugid?

[Rich Felker]

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

Re: issetugid?

[Rich Felker]

On Thu, Jul 17, 2014 at 09:50:42AM +0200, Florian Weimer wrote:
> On 07/16/2014 07:53 PM, Rich Felker wrote:
> >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.
> 
> Yes, this is a bit like complaining that getpid has no error return value.

Yes and no. If the code is only going to be used with glibc, then it's
reasonable to assume that it does not return an error for AT_SECURE.
On the other hand if it's only assuming a more abstract getauxval API,
perhaps it's reasonable to consider failure. For example if running on
a 2.4 kernel with musl, getauxval(AT_SECURE) would return 0 (and set
errno). Having realized this, it's making me think we should probably
provide a fallback value in this case since applications written to
the glibc getauxval API may be assuming it does not fail for
AT_SECURE.

> >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.
> 
> See below; this is related to the issetugid differences.
> 
> >>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.
> 
> FreeBSD's issetugid returns true if the process has altered any of
> the UIDs/GIDs after it has been created ("if it has	changed	any of
> its real, effective or saved user or group ID's since it began
> execution").  In contrast, the Solaris manpage is unaffected by ID
> changes ("The result of a call to issetugid() is unaffected by calls
> to setuid(), setgid(), or other such calls.").
> 
> So FreeBSD issetugid is like prctl(PR_GET_DUMPABLE), and Solaris
> issetugid is like getauxval(AT_SECURE).

Indeed, it seems the FreeBSD version is really weird, at least
according to the manual:

http://www.freebsd.org/cgi/man.cgi?query=issetugid&sektion=2

However they document that it first appeared in OpenBSD, which has the
correct semantics like Solaris and the proposed addition to musl,
according to the OpenBSD man page:

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/issetugid.2

which includes the text:

"The status of issetugid() is only affected by execve()."

So I have no idea why FreeBSD botched the semantics when copying it.
In any case, as far as I can tell, using the FreeBSD version while
expecting the original OpenBSD semantics should only result in false
positives (being overly safe but under-featured due to disallowing
options from the environment) and never false negatives (failing to
identify that the environment needs to be handled securely).

On the other hand it _might_ be a problem to use the OpenBSD version
when expecting the FreeBSD version, but the circumstances under which
it makes a difference are not common. And since all systems which have
this interface, except for FreeBSD, seem to implement it with the
OpenBSD semantics, a cross-platform program assuming FreeBSD semantics
would be rather broken anyway, no?

Rich