fd 0-2 on SUID/SGID program startup

fd 0-2 on SUID/SGID program startup

[Solar Designer]

Rich,

As you're probably aware, glibc makes sure that fd 0-2 are open on
SUID/SGID program startup (opening them to /dev/null / /dev/full if
they're not already open).  This is needed to prevent misdirected
reads/writes by programs that use those well-known fd's (in fact, even
libc itself does) yet also open other files/sockets/whatever (so it may
get opened on one of these special fd's if they're not already taken).

I think musl must have the same countermeasure.  I think it lacks it
currently.

Do you agree?

Alexander

Re: fd 0-2 on SUID/SGID program startup

[Rich Felker]

On Mon, Aug 22, 2011 at 09:07:54PM +0400, Solar Designer wrote:
> Rich,
> 
> As you're probably aware, glibc makes sure that fd 0-2 are open on
> SUID/SGID program startup (opening them to /dev/null / /dev/full if
> they're not already open).  This is needed to prevent misdirected
> reads/writes by programs that use those well-known fd's (in fact, even
> libc itself does) yet also open other files/sockets/whatever (so it may
> get opened on one of these special fd's if they're not already taken).
> 
> I think musl must have the same countermeasure.  I think it lacks it
> currently.
> 
> Do you agree?

Indeed, this is useful, and POSIX explicitly allows that fd 0-2 might
be automatically opened for suid programs. I have an efficient test
using a single syscall:

struct pollfd pfd[3] = { { .fd = 0 }, { .fd = 1 }, { .fd = 2 } };
poll(pfd, 3, 0);

Then check each of pfd[0..2].revents for POLLNVAL:

for (i=0; i<3; i++)
	if ((pfd[i].revents&POLLNVAL) && open("/dev/null", O_RDWR)<0)
		*(volatile char *)0=0;

I assume crashing is the best action on failure to open, but I'd
welcome other ideas... perhaps raising SIGKILL? Plain _exit seems like
a really bad idea as it could be misinterpreted by the parent as a
normal exit.

Rich

Re: fd 0-2 on SUID/SGID program startup

[Rich Felker]

On Mon, Aug 22, 2011 at 09:07:54PM +0400, Solar Designer wrote:
> Rich,
> 
> As you're probably aware, glibc makes sure that fd 0-2 are open on
> SUID/SGID program startup (opening them to /dev/null / /dev/full if
> they're not already open).  This is needed to prevent misdirected
> reads/writes by programs that use those well-known fd's (in fact, even
> libc itself does) yet also open other files/sockets/whatever (so it may
> get opened on one of these special fd's if they're not already taken).
> 
> I think musl must have the same countermeasure.  I think it lacks it
> currently.
> 
> Do you agree?

I committed code that should handle these cases. The only difference
from the suid check in the dynamic linker is that it does not treat
the absence of the aux vector entries as "secure mode". As far as I
know it's a non-issue anyway because there is no remotely-secure
version of Linux which fails to pass a complete aux vector, but in the
case where it's not possible to determine, I considered it more
correct not to mess with fd 0-2, since doing so for non-suid programs
is non-conforming and potentially breaks things badly. If there's any
real-world case where the aux vector is missing/incomplete, perhaps I
could make fallback code that calls gete?[ug]id() to do the check..
I'd welcome input on whether you think it's necessary.

Rich