On Thu, Jul 19, 2012 at 10:10:09AM -0400, Daniel J Walsh wrote: > On 07/19/2012 09:29 AM, Stephen Smalley wrote: > > XSELinux is included in Fedora, but they don't enable it by default so it > > doesn't get much testing. They took a different approach for isolating X > > applications via nested Xephyr servers in their sandbox tool. > > > > My opinion is that XAce or XSELinux works ok with the MLS model, but not with > the type enforcement model. In my opinion isolating applications within the > own sandbox/containers is a simpler and more sustainable approach. > > XClients that get a permission denied, are likely to misbehave (die) since > they were coded with the assumption that they either get full access to X or > no access to X. > > Finally trying to write confinement policy for a type enforcement model on X > is very difficult, how do I isolate two instances of firefox? If Firefox > execs a open office, how does this libreoffice interact with the existing > libreoffice that might be running under a different context. How does > cut/paste work, how about one window obscuring another, transparent windows > ... Way too complicated. Sandbox model is just total separation. They do > not even know the other apps exist. Xephyr is what I have been using so far under Ubuntu. I don't know how it runs under Fedora, but I notice here a performance decrease. Sluggish cursor, sluggish scrolling etc. So I wanted to get away from this. But I think my goals are simple. Right now I have one (standard linux) user as main user and several (standard linux) users as subusers. I have a suid root program that checks a database on disk and allows the main user to drop privileges to one of his subusers. I use a subuser for each job (mail, browser, writing etc.). Seperation under X is achieved using "terminal-chains" (mainuser starts a subuser with X access who starts a terminal and a subuser of his own with no X access who than runs the shell inside the terminal - an idea my brother had years ago), or using "xephyr-chains" which I think is more or less how sandbox does it. Terminal-chains are fast but have no X, xephyr-chains have X but lose performance. What I want to do is to extend the standard linux user seperation to X. Assign the mainuser and every subuser a context and then make sure X-applications in one context can't mess with those in other contexts. Selinux here has only to make sure X is secured. I'll still be using different linux users for every context. I don't need no "fancy stuff" like automatic domain transitions using certain applications as entrypoints. I can perfectly understand the beauty of this in an integrated desktop environment. But something in my wants simplicity when it comes to security concepts. ;-) I'm not exactly sure how MLS works, but I'd intuitively would say, my approach is more MLS-like because change of privileges only goes in one direction. Privileges are only dropped, never gained. (Mainuser drops to subuser, subuser never elevates back to mainuser or any other subuser.) I started working on a policy for X using TE. Do you think, what I want could be better expressed in MLS?
Attachment:
signature.asc
Description: Digital signature
