[PATCH] implement issetugid(2) (v4)

[PATCH] implement issetugid(2) (v4)

[Brent Cook]

From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2

While getauxval(AT_SECURE) might have been able to provide comparable
functionality on the libc versions that support it, several Linux libc
versions implement it in a way such that the results cannot be trusted,
since there is no way to tell if it has failed. Worse, the result of '0'
returned on failures effectively causes the security mechanism to fail
'open'.

There is also no simultaneously reliable and portable way for a
library to identify if the C library has a usable version of getauxval,
since the symbol is unversioned. Compile-time checks for usability are
also unfeasible, since static libraries built with a 'good' version can
be linked to a 'bad' version of getauxval.

The fix is to implement the BSD issetugid(2) interface so that a
portable library can use its presence to determine if the underlying C
library has a reliable way of determining if it is running in a secure
mode.
---
 include/unistd.h       | 1 +
 src/unistd/issetugid.c | 7 +++++++
 2 files changed, 8 insertions(+)
 create mode 100644 src/unistd/issetugid.c

diff --git a/include/unistd.h b/include/unistd.h
index bb19cd8..ac6055a 100644
--- a/include/unistd.h
+++ b/include/unistd.h
@@ -178,6 +178,7 @@ char *getusershell(void);
 int acct(const char *);
 long syscall(long, ...);
 int execvpe(const char *, char *const [], char *const []);
+int issetugid(void);
 #endif
 
 #ifdef _GNU_SOURCE
diff --git a/src/unistd/issetugid.c b/src/unistd/issetugid.c
new file mode 100644
index 0000000..6ffd930
--- /dev/null
+++ b/src/unistd/issetugid.c
@@ -0,0 +1,7 @@
+#include <unistd.h>
+#include "libc.h"
+
+int issetugid(void)
+{
+	return libc.secure;
+}
-- 
1.9.1

Re: [PATCH] implement issetugid(2) (v4)

[Rich Felker]

On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
> >From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
> [...]

In this form, I think the code is now simple, clean, and correct. The
only thing I'd still like to check on is whether it's been proposed to
glibc and whether we can possibly get them on board with providing a
compatible function. While I think it's unlikely that there could be
any incompatibilities in such a simple function, I'd like to foster
the kind of cooperation on adding new interfaces like this that
unifies APIs rather than having each system go their own way and just
add things without consideration for furthering the goals of
compatibility and standardization.

Has anyone contacted the glibc folks yet? If not, would you like me to
do so?

Rich

Re: [PATCH] implement issetugid(2) (v4)

[Brent Cook]

On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@libc.org> wrote:

> On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
>>> From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
>> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
>> [...]
> 
> In this form, I think the code is now simple, clean, and correct. The
> only thing I'd still like to check on is whether it's been proposed to
> glibc and whether we can possibly get them on board with providing a
> compatible function. While I think it's unlikely that there could be
> any incompatibilities in such a simple function, I'd like to foster
> the kind of cooperation on adding new interfaces like this that
> unifies APIs rather than having each system go their own way and just
> add things without consideration for furthering the goals of
> compatibility and standardization.

No, I have not contacted the glibc folks yet. I thought it would make sense to work out the details and discussion with just one C library first, and the ease of building/testing musl made it a no-brainer.

Yes, without a doubt, this would be great to have in glibc too.

> Has anyone contacted the glibc folks yet? If not, would you like me to
> do so?

Yes, if you don’t mind. It looks like it could be implemented in a very simple way there as well.

> Rich

Re: [PATCH] implement issetugid(2) (v4)

[Rich Felker]

On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote:
> On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@libc.org> wrote:
> 
> > On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
> >>> From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
> >> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
> >> [...]
> > 
> > In this form, I think the code is now simple, clean, and correct. The
> > only thing I'd still like to check on is whether it's been proposed to
> > glibc and whether we can possibly get them on board with providing a
> > compatible function. While I think it's unlikely that there could be
> > any incompatibilities in such a simple function, I'd like to foster
> > the kind of cooperation on adding new interfaces like this that
> > unifies APIs rather than having each system go their own way and just
> > add things without consideration for furthering the goals of
> > compatibility and standardization.
> 
> No, I have not contacted the glibc folks yet. I thought it would
> make sense to work out the details and discussion with just one C
> library first, and the ease of building/testing musl made it a
> no-brainer.
> 
> Yes, without a doubt, this would be great to have in glibc too.

So far the response I got from the glibc side has been fairly
negative. Do you have any reaction to the claim that the BSD and
Solaris versions of this function are different/incompatible? As far
as I can tell they're the same.

I agree with them that the name is ugly and something of a misnomer,
but adding yet another function just to "fix" the name on platforms
where this already exists seems silly.

My leaning so far is to include issetugid even if the glibc folks
don't want to, since there seems to be no remotely portable way to
achieve the same thing without it. The suggestion of using getauxval
is much more low-level and tied to particular implementations (ELF or
ELF-like ones with aux vector or which emulate it), and I don't think
it's a reliable approach for applications linked to musl (since they
might be running on a 2.4 kernel). So even if software has to have a
fallback for glibc systems, I'd prefer that it use a libc-provided
issetugid() on musl so that we can provide a reliable answer rather
than asking the caller to make assumptions about the system.

Rich

Re: [PATCH] implement issetugid(2) (v4)

[Brent Cook]

On Jul 16, 2014, at 8:08 PM, Rich Felker <dalias@libc.org> wrote:

> On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote:
>> On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@libc.org> wrote:
>> 
>>> On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
>>>>> From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
>>>> [...]
>>> 
>>> In this form, I think the code is now simple, clean, and correct. The
>>> only thing I'd still like to check on is whether it's been proposed to
>>> glibc and whether we can possibly get them on board with providing a
>>> compatible function. While I think it's unlikely that there could be
>>> any incompatibilities in such a simple function, I'd like to foster
>>> the kind of cooperation on adding new interfaces like this that
>>> unifies APIs rather than having each system go their own way and just
>>> add things without consideration for furthering the goals of
>>> compatibility and standardization.
>> 
>> No, I have not contacted the glibc folks yet. I thought it would
>> make sense to work out the details and discussion with just one C
>> library first, and the ease of building/testing musl made it a
>> no-brainer.
>> 
>> Yes, without a doubt, this would be great to have in glibc too.
> 
> So far the response I got from the glibc side has been fairly
> negative. Do you have any reaction to the claim that the BSD and
> Solaris versions of this function are different/incompatible? As far
> as I can tell they're the same.

In testing, SmartOS and Solaris 11 appears to work the same way as the OpenBSD version.

FreeBSD 9 and 10 work correctly as well.

Solaris 10 has been reported to have a bug, but I wouldn’t call it an incompatible implementation (since they fixed it later anyway):

http://mcarpenter.org/blog/2013/01/15/solaris-issetugid(2)-bug

> I agree with them that the name is ugly and something of a misnomer,
> but adding yet another function just to "fix" the name on platforms
> where this already exists seems silly.

I would agree with you as well about the name on both counts, but it is what it is. There are plenty of bad compatibility-wrapper implementations out there that this would help get rid of at the same time.

> My leaning so far is to include issetugid even if the glibc folks
> don't want to, since there seems to be no remotely portable way to
> achieve the same thing without it. The suggestion of using getauxval
> is much more low-level and tied to particular implementations (ELF or
> ELF-like ones with aux vector or which emulate it), and I don't think
> it's a reliable approach for applications linked to musl (since they
> might be running on a 2.4 kernel). So even if software has to have a
> fallback for glibc systems, I'd prefer that it use a libc-provided
> issetugid() on musl so that we can provide a reliable answer rather
> than asking the caller to make assumptions about the system.

OK, thanks for considering it.

> Rich

Re: [PATCH] implement issetugid(2) (v4)

[Rich Felker]

On Wed, Jul 16, 2014 at 09:33:11PM -0500, Brent Cook wrote:
> > My leaning so far is to include issetugid even if the glibc folks
> > don't want to, since there seems to be no remotely portable way to
> > achieve the same thing without it. The suggestion of using getauxval
> > is much more low-level and tied to particular implementations (ELF or
> > ELF-like ones with aux vector or which emulate it), and I don't think
> > it's a reliable approach for applications linked to musl (since they
> > might be running on a 2.4 kernel). So even if software has to have a
> > fallback for glibc systems, I'd prefer that it use a libc-provided
> > issetugid() on musl so that we can provide a reliable answer rather
> > than asking the caller to make assumptions about the system.
> 
> OK, thanks for considering it.

Based on the discussion so far, I'm going to commit it.

I'm moving the file to a different location though (probably src/misc
unless anyone has a better idea) since the aim (not 100% followed
right now) is to keep the "standard" directories reserved for either
standard functions or nonstandard extensions that clearly belong in
the same functional group (like stdio or thread extensions). Having
issetugid under unistd seems more like a BSD implementation detail
(doing it as a syscall) than a logical grouping. Of course keeping the
prototype in unistd.h makes sense just because we shouldn't break
apps' expectations for where to get it.

The other thing I'd like to do is summarize the discussions of why it
makes sense for musl to adopt this as a commit message. The message in
your email is nice as an argument from the BSD side, but I'd also like
to address why it (and other remarks) have been convincing.

Rich

Re: [PATCH] implement issetugid(2) (v4)

[Rich Felker]

On Sat, Jul 19, 2014 at 04:07:25PM -0400, Rich Felker wrote:
> On Wed, Jul 16, 2014 at 09:33:11PM -0500, Brent Cook wrote:
> > > My leaning so far is to include issetugid even if the glibc folks
> > > don't want to, since there seems to be no remotely portable way to
> > > achieve the same thing without it. The suggestion of using getauxval
> > > is much more low-level and tied to particular implementations (ELF or
> > > ELF-like ones with aux vector or which emulate it), and I don't think
> > > it's a reliable approach for applications linked to musl (since they
> > > might be running on a 2.4 kernel). So even if software has to have a
> > > fallback for glibc systems, I'd prefer that it use a libc-provided
> > > issetugid() on musl so that we can provide a reliable answer rather
> > > than asking the caller to make assumptions about the system.
> > 
> > OK, thanks for considering it.
> 
> Based on the discussion so far, I'm going to commit it.

Committed!

Rich

Re: [PATCH] implement issetugid(2) (v4)

[Brent Cook]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Nice, thanks!
On Jul 19, 2014 8:45 PM, "Rich Felker" <dalias@libc.org> wrote:

> On Sat, Jul 19, 2014 at 04:07:25PM -0400, Rich Felker wrote:
> > On Wed, Jul 16, 2014 at 09:33:11PM -0500, Brent Cook wrote:
> > > > My leaning so far is to include issetugid even if the glibc folks
> > > > don't want to, since there seems to be no remotely portable way to
> > > > achieve the same thing without it. The suggestion of using getauxval
> > > > is much more low-level and tied to particular implementations (ELF or
> > > > ELF-like ones with aux vector or which emulate it), and I don't think
> > > > it's a reliable approach for applications linked to musl (since they
> > > > might be running on a 2.4 kernel). So even if software has to have a
> > > > fallback for glibc systems, I'd prefer that it use a libc-provided
> > > > issetugid() on musl so that we can provide a reliable answer rather
> > > > than asking the caller to make assumptions about the system.
> > >
> > > OK, thanks for considering it.
> >
> > Based on the discussion so far, I'm going to commit it.
>
> Committed!
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1528 bytes --]

Re: [PATCH] implement issetugid(2) (v4)

[Isaac Dunham]

A thought recently crossed my mind regarding getauxval(AT_SECURE):
what does this do under Linux emulation on other platforms?
Most of the BSDs have Linux emulation, as well as Solaris;
there was also LINA for Windows and OS X.
But I haven't found statements about what happens to getauxval().

Thanks,
Isaac Dunham

Re: [PATCH] implement issetugid(2) (v4)

[Rich Felker]

On Sat, Jul 19, 2014 at 04:11:17AM -0700, Isaac Dunham wrote:
> A thought recently crossed my mind regarding getauxval(AT_SECURE):
> what does this do under Linux emulation on other platforms?
> Most of the BSDs have Linux emulation, as well as Solaris;
> there was also LINA for Windows and OS X.
> But I haven't found statements about what happens to getauxval().

Both glibc's and musl's getauxval will just return results from
whatever aux vector the kernel gave the program when it started. If
AT_SECURE is missing from the aux vector the kernel provides, this
will lead to ENOENT on musl and newer glibc, and to a false negative
on old glibc.

For this reason I think musl should intercept the request for
AT_SECURE and simply return libc.secure rather than the value in the
aux vector. In principle applications should be checking for ENOENT,
but since glibc "guarantees" it cannot happen by not supporting
pre-AT_SECURE kernels (and not making any statement about other
kernels with Linux emulation), applications are likely to be skipping
the ENOENT check.

Rich