SELinux and the Desktop

Colin Walters walters at redhat.com
Wed Oct 13 15:00:06 UTC 2004


On Tue, 2004-10-12 at 20:14 -0500, Jerry Haltom wrote:

> 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, 

Not precisely.  System calls aren't directly restricted; there are
simply hooks placed at security-relevant code paths in the kernel.  Not
all system calls are restricted, and not all permissions are obviously
mappable to one particular system call.  Also, you can have userspace
policy enforcers like D-BUS that aren't mappable to kernel syscalls at
all.

> So why can't one program place SELinux policy's on other software? 

SELinux provides mandatory access control, so the policy is generally
controlled centrally by a security administrator.  However, it is
possible right now for the administrator to allow some discretionary
user control over labeling.  That's what the Apache policy does.

> 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?

The problem with this that I see is that it's very difficult to present
this to the user in a meaningful way.  Most users will simply have no
idea what's going on:

> 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

A lot of end users aren't going to know what /tmp, ports, or evolution-
data-server are.  Or even if they do, it's difficult to say whether the
program is actually doing something bad or not.

One major problem is that right now, without Security-Enhanced X, as
soon as you grant an untrusted application access to your X connection
you are screwed.  So it's basically impossible to usefully define a
"user_untrusted_t" domain that downloaded programs could run in; they
wouldn't be able to do anything besides use CPU.  I guess you could pop
them up in a terminal with a suitable program doing filtering with a
pty, but I don't see many people emailing exciting tty-based
applications to each other...







More information about the fedora-selinux-list mailing list