SELinux and the Desktop

[Jerry Haltom]

Howdy. I really have nothing at all to do with Fedora, don't use it. 
Never even seen it. However, you seem to be the only group interested 
in SELinux for the masses, so I'm going to lay out an idea I've had.

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 at larvalstage.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 172 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20041012/be503851/attachment.sig>