On Wed, 2005-06-29 at 11:14 -0500, serue@private wrote: > Attached are the old task_lookup patch which was used by the bsdjail lsm, > a patch for selinux to utilize this hook, and a sample jail policy and > .fc, which presumably would eventually be changed to a jail_domain() > policy macro. Does this seem at all useful by itself, or should this > wait until it were actually needed for a complete linux jails > implementation? What's the real benefit of "hiding" tasks in this manner? SELinux can already prevent processes from accessing anything under /proc/pid for a process in another domain, and procps already conveniently omits entries for any such inaccessible /proc/pid directories, so the typical user experience is the same (i.e. users won't see processes that are inaccessible in ps output) and at most, only the pids are exposed in /proc. > It seems to me the greatest challenge is network jails. I don't think > this can be done right with selinux. I believe you can restrict a > domain's access to remote addresses by IP, but not to local addresses > during bind. Am I wrong in assuming jails would be useless without > this? (I suppose they could at least be useful for sandboxes of some > sort) Does anyone have ideas on a good way to implement these? SELinux has a node_bind check applied upon bind(2) that is based on the address, similar to the name_bind check based on port. However, this doesn't address auto-binding of sockets by the kernel (e.g. when connecting/sending on an unbound socket), and it doesn't make address selection transparent for userspace. > Some time ago I sent out an RFC for network namespaces, which allowed a > process to essentially give up its access to a network device. The > patch only allowed a process to give up access to real network devices, > not ip aliases (ie eth0:0). But this seems much less useful for > allowing admins to provide multiple jails. > > The linux-vserver team is working on virtual networking which (IIUC) > creates a virtual network device which is then associated with a > virtual address, a real network device, and a jail. This appears to > be a way to make the simple version of network namespaces I describe > in the paragraph above more useful, since we would not need to deal > with ip aliases. > > Is there any interest in seeing the virtual network devices and > network namespaces pushed upstream? Yes, although I can't say that I've looked at their approach. > Read-only bind mounts? Not sure what happened to earlier discussions and patches related to that issue on lkml. > The attached task-lookup patches? Not sure it provides much value. -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Wed Jun 29 2005 - 09:36:19 PDT