* Re: issetugid?
[not found] ` <53C78052.9070805@redhat.com>
@ 2014-07-17 15:53 ` Rich Felker
0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2014-07-17 15:53 UTC (permalink / raw)
To: libc-alpha; +Cc: musl
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
^ permalink raw reply [flat|nested] 2+ messages in thread