Re: core statement on fexecve, O_EXEC, and O_SEARCH

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 5 Dec 2012 08:39:55 -0500
    From:        Thor Lancelot Simon <tls%panix.com@localhost>
    Message-ID:  <20121205133955.GA12822%panix.com@localhost>

  | I strongly disagree.  This system call embodies a fairly fundamental
  | shift away from the Unix model ...
  
I know that this thread is mostly about the fexecve (etc) set of calls,
but my message, and the "this system call" that I was referring to was
the ancient exec (or slightly more modern execve) with no 'f' in its name.
  
That related to the message about exec("/proc/self/fds/3", ...) not
working (for reasons no-one has yet managed to work out).
   
When talking of exec, and not fexec, to be consistent with the unix
model, checking permissions on the file at the time of the exec() is
the only way that makes sense - if you don't want to permit exec in
this kind of case, then /proc could me mounted noexec, or x permission
could be omitted, but if neither of those has been done, and the
file has a suitable magic number, exec should succeed (from a logical
viewpoint, I don't care much whether whatever bug that is preventing
it working now ever gets fixed or not - though it would be nice for it
to be understood).
  
Most of your message concentrated on fexecve(), rather than on
execve(), so I'm not going to attempt to respond to any of that.
I'm not sure that I really like the f*() (file system access via fd)
sys calls at all.

  | The chroot system call isn't, itself, a
  | security mechanism, but it can be an important building block for such
  | mechanisms.  It is the only means of namespace restriction we have.
  
Of course.   The question is whether doing everything else that is
necessary to actually provide an adequate security mechanism (perhaps
the entire new kauth type security model that Aleksey mentioned in
another message) is worth the bother, and if that's done, whether the
result is actually useful enough for (all of) the purposes for which
we would like to have a restricted environment.

And that question needs to be considered with the knowledge that we
now have, reasonably easily available, a true VM environment that
will generally be possible in most places where this kind of
security is really needed, and that that environment gives a full
featured (yet as safe as it can be) environment, with no weird
surprises - for example, if a process in such an environment
needs to alter the time, it can - without affecting the rest of the
system processes, and without the kernel needing a concept of per process
time.   And so on for everything else.   And without needing a whole
new security model that needs to be understood, and debugged.

kre