This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Error checking for SETXID (bug 13347)
- From: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 27 Mar 2014 11:21:10 -0400
- Subject: Re: [PATCH] Error checking for SETXID (bug 13347)
- Authentication-results: sourceware.org; auth=none
- References: <53304186 dot 4000909 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1403241516210 dot 6513 at digraph dot polyomino dot org dot uk> <53305247 dot 7070605 at redhat dot com> <20140324182208 dot GV26358 at brightrain dot aerifal dot cx> <533429EE dot 7040906 at redhat dot com>
On Thu, Mar 27, 2014 at 02:38:54PM +0100, Florian Weimer wrote:
> On 03/24/2014 07:22 PM, Rich Felker wrote:
>
> >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.
>
> I think you are wrongâthe kernel does it all the time. It is okay
The kernel does a lot of things that are not good security practices.
Appeal to authority is not a valid argument.
> as long as you can control what code you run.
>
> We already support it through setfsuid/setfsgid, which is
> per-thread, not per-process.
The whole reason you're changing uids is because you can't be sure
about what code you run; your code could (and probably does) have
arbitrary code execution vulnerabilities you're not aware of. This is
why you use privilege separation enforced by the kernel/mmu/etc.
rather than just assuming your code is all safe and correct. If, after
calling setuid with the intent of fully dropping root privileges, the
code that subsequently runs has write access to memory used by a code
that continues to run with root privileges, it's trivial for an
exploit in the "unprivileged" code to elevate itself to compromise of
the code that's still running with privileges.
Rich