From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5466 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] implement issetugid(2) Date: Sat, 12 Jul 2014 16:32:15 -0700 Message-ID: <20140712233214.GB25353@newbook> References: <1405187706-27171-1-git-send-email-bcook@openbsd.org> <20140712192017.GO179@brightrain.aerifal.cx> <6DC27FFF-D350-4CF8-A95E-664C042511DA@openbsd.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1405207957 2918 80.91.229.3 (12 Jul 2014 23:32:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 23:32:37 +0000 (UTC) Cc: Rich Felker , Bob Beck To: musl@lists.openwall.com Original-X-From: musl-return-5471-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 13 01:32:33 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X66mP-0003J2-3m for gllmg-musl@plane.gmane.org; Sun, 13 Jul 2014 01:32:33 +0200 Original-Received: (qmail 16293 invoked by uid 550); 12 Jul 2014 23:32:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16285 invoked from network); 12 Jul 2014 23:32:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=tVvjWxBYeBhVL7vb04MJ0lnC6hRVjLwqoEXB/V7tRnQ=; b=FQ856NAD4K93N70kGW4DfyBkES1akRYkfqzwJxXiW7LFjWpgWjwoD9F+fh5WQQ7+3h NGqQuM1gkHrlOpJqMFtrnxx9CQO/dVERbqPkTC1GdSHYNfWG1IZY4KTLFHtvZNgqbb1/ fJ5oaE7Ds3P0YaKV1D+pl5HjSR0MSKIYWm48BTBDsZFzLV8Do7x5zdCyOTAlkBucU4xv VSJqqaATAU37AzZWJ8O0cr4UJT9qPCpfeBzGkugboPwY0gQkHfCgN2947auim4znULaP HsEmy7xGI+JYpxHvx3y5B5rEIXh+xxkldMqLI1tWpgbbJaY0T+fMjEvwiY3RJvCuimvZ FPLg== X-Received: by 10.68.237.67 with SMTP id va3mr7566484pbc.19.1405207938964; Sat, 12 Jul 2014 16:32:18 -0700 (PDT) Content-Disposition: inline In-Reply-To: <6DC27FFF-D350-4CF8-A95E-664C042511DA@openbsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5466 Archived-At: On Sun, Jul 13, 2014 at 12:18:25AM +0200, Brent Cook wrote: > > On Jul 12, 2014, at 9:20 PM, Rich Felker 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 > >> +#include > >> +#include > >> + > >> +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