Michael Stone <[EMAIL PROTECTED]> wrote: > > However, a quick look at relevant Rainbow docs (specifically [2]) > > indicate that Rainbow might be implemented using only the standard Linux > > DAC mechanisms -- essentially, very similar to the Polaris design[3]. > > Correct to date, though we've basically reached the limits of the > existing DAC framework. Clever (or stupid, depending on your > perspective) hacks now seem to be required. For network isolation, I'm > currently intending to go forward with compartmentalized "network" and > "not-network" processes based on Dan Bernstein's sys_disablenetwork() > idea [2]. > > [2]: http://cr.yp.to/unix/disablenetwork.html
That is the approach I would like to take with Plash for limiting network access. In general, I would like to be able to disable most system calls, leaving only those that deal purely with file descriptors (as listed on http://plash.beasts.org/wiki/PtraceJail). One way to do that would be to use ptrace(), possibly with Jeff Dike's PTRACE_SYSCALL_MASK patch. > For X, I'm still at the research stage, currently investigating both > XACE [3] and an off-the-cuff idea involving per-uid Xephyrs (or > similar tomfoolery). I have been investigating this area and there are some notes on the Plash wiki: http://plash.beasts.org/wiki/X11Security http://plash.beasts.org/wiki/X11SecurityRequirements I expect that Sugar's X security requirements would be easier to meet than mine, since Sugar's GUI is much simpler, lacking a conventional window manager with overlapping windows. What are you considering doing with Xephyr? I have considered adapting Xnest to support a rootless mode (similar to Cygwin X's rootless mode) in which Xnest's top-level windows co-exist among the parent X server's top-level windows, instead of appearing inside a nested window. It did not appear to be practical because Xnest re-uses all of a normal X server's keyboard and mouse input processing, including grab processing. I have investigated XACE and decided against using it for reasons that are partly architectural and partly practical. The idea of filtering X requests does not fit with Plash's aim of having a capability architecture. Since XACE is just a set of internal server hooks, it requires a lot to be done on the server side. I am not convinced that my requirements for handling top-level windows and proxying access to the X clipboard can be achieved using something like XACE without putting a lot of complexity into the X server. I have been experimenting with writing a security-enforcing X proxy. I've got an incomplete prototype written in Python: http://plash.beasts.org/wiki/X11ProxySpike > P.S. - It sounds like our goals are closely aligned with some of the > goals of the Plash project - also, OLPC has no desire to maintain > bespoke security software just for kicks. Can you suggest some an > approachable Plash developer (or mailing list?) to suggest that we > explore ways to further our mutual aims in concert? I'm the main Plash developer. I read this list but you're welcome to post on Plash's mailing list (http://lists.nongnu.org/mailman/listinfo/plash) or cross-post. I've been on this list since Bitfrost was announced. It's good to hear some more details about the planned implementation. I don't think I knew before today that the implementation is called Rainbow! Regards, Mark _______________________________________________ Security mailing list [email protected] http://lists.laptop.org/listinfo/security
