Re: [PATCH] Error checking for SETXID (bug 13347)

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Mar 24, 2014 at 04:41:59PM +0100, Florian Weimer wrote:
> On 03/24/2014 04:19 PM, Joseph S. Myers wrote:
> >On Mon, 24 Mar 2014, Florian Weimer wrote:
> >
> >>Check for syscall error in the SETXID implementation in NPTL (bug 13347).
> >>
> >>At this point, we can only abort the process because we have already switched
> >>credentials on other threads.  Returning an error would still leave the
> >>process in an inconsistent state.
> >
> >This may be the best possible in the absence of a kernel interface for
> >setting ids atomically for the whole process, but such an interface would
> >be the desired long-term fix, with aborting from the present code just a
> >fallback - is there ongoing work to agree such an interface?
> 
> As far as I know, the credentials switching work goes in the other
> direction, providing additional per-thread credentials to
> glibc-based userspace:
> 
>   <http://thread.gmane.org/gmane.linux.file-systems/81751>
> 
> Probably like most kernel developers, I'm not convinced that the
> POSIX semantics are useful.

It is a critical security flaw to have multiple tasks
(threads/processes) running in the same virtual address space with
different privileges. I have described potential attacks for this
situation before; I could lookup the references if you care.

BTW, normally it's a bad idea to call setuid in a multithreaded
program anyway. However the situation does arise quite often,
especially in programs written in higher-level languages like Java
where the language runtime may have started threads for its own
internal purposes before the program drops privileges via a FFI-like
interface to the low-level libc functions like setuid. I've seen this
issue before in software I've audited. So glibc needs to handle it
correctly, Linux should too at the kernel level, and the
POSIX-specified behavior is "right" from a security standpoint.

Rich