SELinux has a place on the desktop.
Currently, a large piece is missing from the desktop security landscape. User's can receive, by email or IM, executable files. These can be in the form of actual real binaries, pseudo-binaries (flash), or script languages (javascript, html, etc). Up to now the current attitude has been "don't open files you don't trust, don't go to websites you don't trust, don't run scripts you don't trust". This "rule" ignores one common principle. 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? I don't think so.
So here's where SELinux comes in. SELinux allows the system to place restrictions on executable programs beyond that offered by the user identity itself. It allows you to audit, and deny syscall execution, which is every programs interface to the world.
So why can't one program place SELinux policy's on other software? Why can't a desktop interface listen for faults in SELinux, change those policy's based on the user's actions or requests, and let the program continue, at runtime?
Consider the following example:
Bob receives an executable from his co-worker Joe. Bob opens it from his email. His email client sets up a policy restricting all access to everything, except maybe /tmp, and the obvious, the program runs. Oh no! It's a virus! The program attempts to establish a connection to Bob's address book (exposed by evolution data server). SELinux detects the programs attempts to open a socket that it was not allowed to do. The program blocks on the syscall. SELinux is configured to continue blocking the program until told otherwise. SELinux locates a D-BUS daemon for Bob and notifies it about the security event. Running as Bob is sec-policy-daemon which is listening to D-BUS for fault notifications. This daemon reads the information Bob's email client attached to the process. The information reads as follows:
1) don't allow the program to do anything except read/write to /tmp 2) do allow the program to open outgoing ports after notifying the user
The daemon realizes that the action isn't allowed, but that it could be allowed if the user consents to it, so the daemon pops up on the user's desktop a nice dialog box, "The application Blah has attempted to access the file /tmp/contact-socket (or whatever). Do you want to allow this action?" Most likely t his dialog would ask for the user's password again. Upon receiving a "Yes", SELinux would be instructed to allow the program to access the socket. If the user presses Yes, the process ceases being blocked, and goes on. In the case of No, the process will probably die. ;0
Of course this policy would be configurable. In some offices admins would probably not want the user to even have the option to open outgoing ports from downloaded software, they just don't wnat to take the risk. In some home circumstances, it might be a little bit looser. It's up to you.
What this does is let users do what they will do anyways: run the program. You won't stop them, I won't stop them, and we probably shouldn't. We should make it so they CAN without risk to their systems.
Do enjoy. I hope you guys do something with this. It's what we need.
Jerry Haltom wasabi@xxxxxxxxxxxxxxx
Attachment:
PGP.sig
Description: PGP signature
