On Thu, 15 Nov 2012 11:03:15 -0500 Thor Lancelot Simon <tls%panix.com@localhost> wrote: > 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. > > If there is not some explanation I am missing for why this doesn't > basically blow up chroot's security in the very common case where > chroot is used to build a W^X environment, I am strongly opposed to > ever including this system call in NetBSD. > > I'm sure the Linux crowd don't care, since they deliberately and > proudly punted on actually being able to contain any misbehaving > process within a chroot long ago. But that's not us. As you mention Linux, their man page for fexecve states “The file descriptor fd must be opened read-only, and the caller must have permission to execute the file that it refers to.” It sounds like that might be what you're missing? I certainly interpret it to mean that if you can't execve the file, you can't fexecve a FD to it either. From the spec: “The purpose of the fexecve() function is to enable executing a file which has been verified to be the intended file. It is possible to actively check the file by reading from the file descriptor and be sure that the file is not exchanged for another between the reading and the execution.” ...which seems a reasonable enough thing to want to do. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012%jry.me@localhost>
Attachment:
signature.asc
Description: PGP signature