On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote: > Quoting Crispin Cowan (crispin@xxxxxxxxxxxxxxxx): > > Just the name "sys_hijack" makes me concerned. > > > > This post describes a bunch of "what", but doesn't tell us about "why" > > we would want this. What is it for? > > Please see my response to Casey's email. > > > And I second Casey's concern about careful management of the privilege > > required to "hijack" a process. > > Absolutely. We're definately still in RFC territory. > > Note that there are currently several proposed (but no upstream) ways to > accomplish entering a namespace: > > 1. bind_ns() is a new pair of syscalls proposed by Cedric. An > nsproxy is given an integer id. The id can be used to enter > an nsproxy, basically a straight current->nsproxy = target_nsproxy; > > 2. I had previously posted a patchset on top of the nsproxy > cgroup which allowed entering a nsproxy through the ns cgroup > interface. > > There are objections to both those patchsets because simply switching a > task's nsproxy using a syscall or file write in the middle of running a > binary is quite unsafe. Eric Biederman had suggested using ptrace or > something like it to accomplish the goal. > > Just using ptrace is however not safe either. You are inheriting *all* > of the target's context, so it shouldn't be difficult for a nefarious > container/vserver admin to trick the host admin into running something > which gives the container/vserver admin full access to the host. I don't follow the above - with ptrace, you are controlling a process already within the container (hence in theory already limited to its container), and it continues to execute within that container. What's the issue there? > That's where the hijack idea came from. Yes, I called it hijack to make > sure alarm bells went off :) bc it's definately still worrisome. But at > this point I believe it is the safest solution suggested so far. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
