[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Jul 2014 16:32:15 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>, Bob Beck <beck@...nbsd.org>
Subject: Re: [PATCH] implement issetugid(2)
On Sun, Jul 13, 2014 at 12:18:25AM +0200, Brent Cook wrote:
>
> On Jul 12, 2014, at 9:20 PM, Rich Felker <dalias@...c.org> wrote:
>
> > On Sat, Jul 12, 2014 at 11:55:06AM -0600, Brent Cook wrote:
> >>> From OpenBSD 2.0 and later
> >> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
> >> ---
> >> include/unistd.h | 1 +
> >> src/unistd/issetugid.c | 9 +++++++++
> >> 2 files changed, 10 insertions(+)
> >> create mode 100644 src/unistd/issetugid.c
> >>
> >> diff --git a/include/unistd.h b/include/unistd.h
> >> index bb19cd8..30290c3 100644
> >> --- a/include/unistd.h
> >> +++ b/include/unistd.h
> >> @@ -109,6 +109,7 @@ uid_t geteuid(void);
> >> gid_t getgid(void);
> >> gid_t getegid(void);
> >> int getgroups(int, gid_t []);
> >> +int issetugid(void);
> >> int setuid(uid_t);
> >> int setreuid(uid_t, uid_t);
> >> int seteuid(uid_t);
> >> diff --git a/src/unistd/issetugid.c b/src/unistd/issetugid.c
> >> new file mode 100644
> >> index 0000000..8c81336
> >> --- /dev/null
> >> +++ b/src/unistd/issetugid.c
> >> @@ -0,0 +1,9 @@
> >> +#include <errno.h>
> >> +#include <unistd.h>
> >> +#include <sys/auxv.h>
> >> +
> >> +int issetugid(void)
> >> +{
> >> + errno = 0;
> >> + return !(getauxval(AT_SECURE) == 0 && errno != ENOENT);
> >> +}
> >> --
> >> 1.9.1
> >
> > If this interface is to be added, it should be consistent with the
> > internal logic and use libc.secure, not getauxval(AT_SECURE).
>
> OK, that makes sense.
>
> > The
> > proposed code above presumably gives false positives for old kernels
> > where AT_SECURE did not exist, whereas the internal libc logic also
> > checks AT_E?[UG]ID.
> >
> > Rich
>
> Yes, the intent is that the function will fail securely if AT_SECURE is not present.
>
> EUID/EGID checks alone do not provide the same guarantee that AT_SECURE does, since it does not consider capabilities:
>
> http://lxr.free-electrons.com/source/security/commoncap.c#L590
>
> There does not seem to be a good reason for a security mechanism to fail in a weaker way than it would if it succeeded.
As far as I can tell, no kernels supported a way to gain capabilities at
binary load time other than setuid/setgid while not supporting AT_SECURE.
The original patch to add AT_SECURE simply tested for
euid != uid || egid != gid, and had this comment:
/* If/when this module is enhanced to incorporate capability
bits on files, the test below should be extended to also perform a
test between the old and new capability sets. For now,
it simply preserves the legacy decision algorithm used by
the old userland. */
The patch adding this was against kernel 2.5.x, so no supported kernel
precedes this. But 2.4.x kernels may still be used on rare occasions.
Note: while it's probably possible to reset euid/egid and drop
privileges while keeping some capabilities in older kernels,
the values in question tell the status at load time--
before the application can do that.
Hope this helps,
Isaac Dunham
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.
