From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5464 Path: news.gmane.org!not-for-mail From: Brent Cook Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] implement issetugid(2) Date: Sat, 12 Jul 2014 23:23:14 +0200 Message-ID: <88E37E71-33ED-4D8A-9188-E6522518F7B7@openbsd.org> References: <1405187706-27171-1-git-send-email-bcook@openbsd.org> <20140712201239.GC4471@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1405200338 26616 80.91.229.3 (12 Jul 2014 21:25:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2014 21:25:38 +0000 (UTC) Cc: musl@lists.openwall.com, Bob Beck To: Isaac Dunham Original-X-From: musl-return-5469-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 12 23:25: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 1X64nT-0005rq-TE for gllmg-musl@plane.gmane.org; Sat, 12 Jul 2014 23:25:32 +0200 Original-Received: (qmail 16109 invoked by uid 550); 12 Jul 2014 21:25: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 15721 invoked from network); 12 Jul 2014 21:23:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zM3zMeO7i95DnaZQ1tqI6w77cYSof5sPpFPxTk93Zp0=; b=HWUKXwxWISoyzfUe1gR/6UdEU6HKgORcwDf+37GMldnR5Nswhim0vKCEXRnSr055e1 3zRsE6o+Eem7OttZEcvQmd87/P6qWhhVxDTO6BrKXpcOw9RIAV9UtSf3a/vqxOJLATBk 3PhWymLNeUPGM8ZcPj+0SbWmGQW385nHzX5hNF5ny1C2O7sFnnPXioq+ohCy0W/6HPfR riFc3yG0JQf0tj6X2SIuC85VY+4RLQks86S9NoxBBJOXkrA9axjIHJWnhKR1VNTstM/w YfN/qJ8t6e3OQotSVRuKHA0bvi5sB7pGkaOnRXq8HN+ePuuv1lv8uhibIzxy2MZYMnK6 u/UQ== X-Received: by 10.182.236.162 with SMTP id uv2mr8269818obc.12.1405200197477; Sat, 12 Jul 2014 14:23:17 -0700 (PDT) X-Google-Original-From: Brent Cook In-Reply-To: <20140712201239.GC4471@newbook> X-Mailer: Apple Mail (2.1878.6) Xref: news.gmane.org gmane.linux.lib.musl.general:5464 Archived-At: On Jul 12, 2014, at 10:12 PM, Isaac Dunham wrote: > On Sat, Jul 12, 2014 at 11:55:06AM -0600, Brent Cook wrote: >> =46rom OpenBSD 2.0 and later >> http://www.openbsd.org/cgi-bin/man.cgi?query=3Dissetugid&sektion=3D2 >> --- >> include/unistd.h | 1 + >> src/unistd/issetugid.c | 9 +++++++++ >> 2 files changed, 10 insertions(+) >> create mode 100644 src/unistd/issetugid.c >=20 > Hello Brent Cook, > Would you mind giving an explanation of the rationale when you=20 > add functions? >=20 > My understanding is that this patch arose from an issue with > libressl-portable. libressl needs to check if it's running in > privileged code; while getauxval() is the simplest way to check on > Linux systems, it's unreliable. > Specifically, getauxval() on glibc < 2.19, klibc, and on bionic will = not > set errno if it cannot check AT_SECURE, but only returns 0. > uclibc does not implement this, and I see no reference to dietlibc > or newlib implementations. > Given the number of known-bad versions, expecting an unknown version = to > set errno is excessivey optimistic. > So libressl cannot trust getauxval() unless it's known to be a version > that sets errno; this currently means glibc 2.19+ or musl. > glibc did not version getauxval when they fixed it to set errno, so = relying > on symbol versioning will not prevent running against lower versions. >=20 > (But might other versioned functions that libressl uses prevent > using older glibc versions with libressl built against glibc 2.19+?) This is a fair point. Compile-time tests were ruled out because static libraries can be built = against a safe libc, then linked to an app that uses an unsafe libc, = causing a vulnerability. For example, here I have built a static libressl library with musl-gcc, = then a link a program with the resulting library using glibc: $ touch crypto/compat/arc4random.c $ make V=3D1 Making all in crypto make[1]: Entering directory `/home/bcook/libressl-2.0.0/crypto' /bin/bash ../libtool --tag=3DCC --mode=3Dcompile musl-gcc = -DPACKAGE_NAME=3D\"libressl\" -DPACKAGE_TARNAME=3D\"libressl\" = -DPACKAGE_VERSION=3D\"2.0.0\" -DPACKAGE_STRING=3D\"libressl\ 2.0.0\" = -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE_URL=3D\"\" -DPACKAGE=3D\"libressl\" = -DVERSION=3D\"2.0.0\" -DSTDC_HEADERS=3D1 -DHAVE_SYS_TYPES_H=3D1 = -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1 -DHAVE_STRING_H=3D1 = -DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1 -DHAVE_INTTYPES_H=3D1 = -DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_DLFCN_H=3D1 = -DLT_OBJDIR=3D\".libs/\" -DHAVE_GETAUXVAL=3D1 -I. -I../include = -DOPENSSL_NO_ASM -DHAVE_CRYPTODEV -DLIBRESSL_INTERNAL -I../crypto/asn1 = -I../crypto/evp -I../crypto/modes -Wall -std=3Dc99 -g -D_BSD_SOURCE = -D_POSIX_SOURCE -D_GNU_SOURCE -O2 -Wall -std=3Dc99 -g -D_BSD_SOURCE = -D_POSIX_SOURCE -D_GNU_SOURCE -MT compat/libcompat_la-arc4random.lo -MD = -MP -MF compat/.deps/libcompat_la-arc4random.Tpo -c -o = compat/libcompat_la-arc4random.lo `test -f 'compat/arc4random.c' || echo = './'`compat/arc4random.c ..library builds.. $:~/libressl-2.0.0$ cat test.c #include int main() { printf("arc4random %u\n", arc4random()); } $:~/libressl-2.0.0$ gcc test.c crypto/.libs/libcompat.a = crypto/.libs/libcrypto.a $:~/libressl-2.0.0$ ./a.out arc4random 565490330 $:~/libressl-2.0.0$ ldd a.out linux-vdso.so.1 =3D> (0x00007fffff492000) libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 = (0x00007f2fde3b3000) /lib64/ld-linux-x86-64.so.2 (0x00007f2fde78e000) With the requirement of issetugid, we get a link-time failure instead: $ cat test.c #include int main() { printf("issetugid %u\n", issetugid()); } $ gcc test.c ./crypto/.libs/libcompat.a /tmp/ccPenDq1.o: In function `main': test.c:(.text+0xa): undefined reference to `issetugid' collect2: error: ld returned 1 exit status $ musl-gcc test.c ./crypto/.libs/libcompat.a $ ./a.out issetugid 0 >=20 > My guess is that the logic here is that a system providing issetugid() > can be assumed to have a working version, unlike getauxval(). >=20 > Is that the reason for this? Yes, this is an excellent summary of the issue. I should have been = clearer in the initial presentation. >> 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); >=20 > This part is a namespace violation. > issetugid() should be conditional on _BSD_SOURCE if it is added, since > unistd.h is in POSIX. OK, I do not think that this would be a problem. >> 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 =3D 0; >> + return !(getauxval(AT_SECURE) =3D=3D 0 && errno !=3D ENOENT); >> +} >> -- >> 1.9.1 >>=20