SELinux and the Desktop

[Steve Coleman]

Jerry Haltom wasabi-at-larvalstage.net |fedora| wrote:

> USERS DONT CARE! It doesn't matter that they SHOULDN"T open an 
> executable their friend or co-worker sends them, they will anyways. Is 
> this so bad?

In a word, yes. By your own definition they are not security experts, so 
they don't know what they are supposed to do and they will gladly click 
on any button that they think will show them what they think they are 
supposed to see happen. If the "yes" button does not work then they will 
download it again and try the "no" button instead. Trial and error is 
not what SELinux is about.

> The daemon realizes that the action isn't allowed, but that it could 
> be allowed if the user consents to it,

My congradulations to this user, as they are now a certified security 
officer (lol), so they *must* know which is the best button to click on. 
Will that be door number one, ... or door number two? Or you can trade 
it all for ... a ..BRAND.. NEW.. JOB!! (ding) (ding) (ding). Oh, sorry, 
got carried away for a sec. ;)

Even pavlov's dog understood the suggestive power of repetition, so if 
they clicked "yes" three times in a row last week there is about a 90% 
probablility they will click the "yes" button today without even reading 
the text of the yes/no box. If your going to give them a choice then you 
are going to have to train them how to be smart about it, or create a 
*corporate policy*, but then you already said they will just ignore that.

>  In the case of No, the process will probably die. ;0

I also think the desktop should have some smarts built in, but my vote 
would be to have the "desktop" send a sigterm to the errant process and 
put up a "don't do that!" modal dialog box for which the user has to 
acknowlege in order to continue. Of course I can't ignore the 
possibility that a user might actually *need* to run a binary given to 
them, for which I would propose that it be 1) "signed" (just warm fuzzy 
feeling, but not a true protection methodology) and 2) run in a *real* 
partitioned Virtual Machine, sandbox a la VMWare/Plex86/etc. or as near 
as one can get to that, such as a chrooted sandbox with a very 
restrictive SE policy.

This does bring to mind a burning question I have always had reguarding 
some applications such as Java where the binary itself is too open ended 
and where as the compiled class files, script file, or data dictate what 
the runtime will do. I assume that many desktop environments (take your 
pick) will have some form of builtin scripting support. How does SELinux 
deal with these VM's? Is there any good docs online that discuss the 
problems and current solutions that these present? Do they get their 
security context from the script or data streams?

Thanks!