Date: Tue, 4 Dec 2012 15:44:47 +0300
From: Alan Barrett <a...@cequrux.com>
Message-ID: <20121204124447.gf8...@apb-laptoy.apb.alt.za>
| >>> The fexecve function could be implemented entirely in libc,
| >>> via execve(2) on a file name of the form "/proc/self/fd/<N>".
| >>> Any security concerns around fexecve() also apply to exec of
| >>> /proc/self/fd/<N>.
| >>I gave a try to this approach. There is an unexpected issue:
| >The descriptor is probably already "closed on exec" before the syscall
| >tries to use it.
I doubt that is the problem, I took a quick look, and couldn't see the
cause either, but I suspect something related to the files really
not truly existing, but just appearing when they're referenced (or
on a directory read) is the root cause of the "problem".
| I believe that we should not "fix" that without a proper design
| of how all the parts will work together.
First, I'm not sure it is really worth fixing at all, this doesn't
seem to be a particularly big problem in reality. But, that said,
if a file exists, has x permission, and there's something executable
behind it, then exec should work on it, and there really should be
no need to look further than that.
| Some questions that I would like to see answered are: Should it
| be possible to exec a fd only if a special flag was used in the
| open(2) call?
The questin here isn't really execing a fd, its execing a named file
(that happens to refer to an open fd, bt that shouldn't be important).
| Should the file's executability be checked at open
| time or at exec time, or both,
For this use, at exec time, the fd refers to a file, this should be
not be different than an exec of a symlink. We just have a slightly
different way if getting a reference to the file to be exec'd.
Half of the issues here all relate to how people see chroot(2) I think.
If we ignored chroot completely, most of what are seen as problems
would go away, and almost all of the issues could be resolved.
Even chroot isn't a problem, unless you're tempted to view it as some
kind of security mechanism. It really isn't - it is just namespace
modification. Sure, by modifying the filesystem namespace a bunch
of simple security attacks seem easy to avoid (and it does provide
some simple measure of protection) but as a true security mechanism
it really doesn't come close, and arguing against feature X or Y
because some tricky application of it can defeat chroot "security"
is just plain insane.
If true compartmentalisation is wanted for security purposes, we would
need something approaching true VM (like Xen DomU's or whatever) where
the whole environment can be protected, not just the filesystem.
chroot provides no protection at all to processes killing others,
reconfiguring the network, binding to random ports, thrashing the CPU,
altering sysctl data, rebooting the system, ... There's almost no end
to the harm that a sufficiently inspired (and privileged) rogue process
can do, even if it is running in a chroot.
If we were willing to abandon the fiction that chroot is some kind of
security mechanism, then we can mostly just ignore it for almost all
purposes, and not worry about whether it would be possible to exec
a file via a fd passed through a socket to a process inside a chroot,
and all of that nonsense, as no-one would care one way or the other.
kre
