Re: [PATCH] Linux: Implement per-thread user and group IDs

[Florian Weimer <fweimer at redhat dot com>]

* Rich Felker:

> On Fri, Jun 28, 2019 at 08:54:05PM +0200, Florian Weimer wrote:
>> This commit adds the functions pthread_attr_setperthreadids_np and
>> pthread_attr_getperthreadids_np.  Threads created with the new flag
>> will be exempted from the setxid broadcast.  setuid and related
>> functions will only update the credentials for the current thread.
>> 
>> Multi-threaded file servers typically need this functionality and
>> call the system calls directly to implement this.
>
> From a security standpoint, this is a really bad idea. Given a set of
> tasks sharing virtual address space, the individual privilege of each
> is effectively the union of the privileges of them all, simply because
> each has the capacity to undermine the execution integrity of all the
> others.

If a task has the capability to call setresuid, it can already achieve
the same thing by calling the system call directly.  All system calls
operate on a per-task credential structure, not a process-wide one.

Even if tasks with different credentials share the same address space,
this does not make those credentials equivalent.  It is still necessary
to affect execution in such a way that one task performs an action on
behalf of another task which has different credentials.  Whether this is
more difficult or easier if a new process is spawned for each different
credential depends on many factors.

> For fsuid/fsgid, we already have per-thread behavior, and it's
> somewhat reasonable because there's an understanding that this is
> *not* restricting the privilege of the thread, just performing fs
> access "as if" by another user/group (you always have the privilege to
> revert fsuid/fsgid changes anyway). The useful part of the new
> functionality your patch adds seems to just duplicate this, and the
> remainder of the new functionality all seems actively dangerous,
> creating a false impression that you can make isolated security
> contexts as threads within a process.

setfsuid and setfsgid do not allow any error checking, so you have to
parse /proc to see if the kernel gave you the requested values.
Originally, they were introduced because at the time, the kernel would
allow sending signals to processes whose effective user ID was the same
as the current process.  That is obviously bad if a file server changes
effective IDs to get permission checking as that user from the kernel
because it allows the user to terminate the server process.  Today,
effective IDs are no longer used for signal permission checks, and
fsuid/fsgid is obsolete.

And on most systems, fsuid/fsgid alone allows full escalation to the
target user anyway, via dotfiles and similar mechanisms.

Thanks,
Florian