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
