[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] fexecve
On Thu, Nov 15, 2012 at 01:16:27PM -0500, Mouse wrote:
> >> Here is a patch that implements fexecve(2) for review:
> > This strikes me as profoundly dangerous. Among other things, it
> > means you can't allow any program running in a chroot to receive
> > unix-domain messages any more since they might get passed a file
> > descriptor to code they should not be able to execute.
> Let me phrase that a bit differently:
> This gives you the ability to give a chrooted process access to
> outside-chroot executables in a controlled way.
Who is the "you"? It seems to me it's anything outside the chroot
that can send to a socket anywhere within it.
And that means that you can't really build a TCB inside a chroot,
where you can be sure that any storage that is writable is not executable,
unless you make it impossible for anything on the outside to write in.
That's a major semantic change and not one I think we should make. It
will impact real-world systems that use chroot and role accounts to
separate application-level privilege. In fact, I built a system like
that that's in a fairly widely deployed embedded product, in which
file-descriptor passing over sockets is an intentional part of the
message-passing protocol that glues the components together.
All of a sudden, the very presence of those sockets means not just that
a component A running in chroot Ca, with uid Ua, can pass _data_ to a
component B running in chroot Cb, with uid Ub -- which was part of the
design -- but that it can enable B to run new code that was formerly
not available at all in Cb (because all memory and filesystems available
to processes in Cb are either read-only, or executable, but not both).
That just sucks.
Main Index |
Thread Index |