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!
