Re: [PATCH] fexecve

[Thor Lancelot Simon <tls%panix.com@localhost>]

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.

Thor