Re: Information about XSELinux

[Ole Kliemann <ole@plastictree.net>]

[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]