Date: Wed, 5 Dec 2012 08:39:55 -0500 From: Thor Lancelot Simon <t...@panix.com> Message-ID: <20121205133955.ga12...@panix.com>
| 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