Today's discussion of SELinux was somewhat spontaneous (I planned to
talk about SELinux at a later time), but it was sparked at just the
right question: what determines the permissions of a process (or, to
put it more fancily, the "identity" of a process), and what designs
make sense?

Unix user accounts originated in the times when a machine's universe
was its files -- and "everything was a file", i.e., every resource
worth controlling access to was mapped to a file, with some ownership
and respective permissions. 

The "stickiest wicket" in that design was the downward
limited/temporary delegation of privilege, which is inevitable in any
practical system (or else the possessor of a higher privilege gets
swamped with approving requests to do something that underlings need,
and could in principle be trusted to do by themselves as a one-off, if
it were not for the rules). That brought to life the suid mechanism of
privilege delegation to "effective user id" or "effective group id"
for the delegated task. For the analysis of the complexity failures of
that mechanism, see
http://unixwiz.net/techtips/mirror/setuid-usenix02.pdf

As Unix systems became the backbone of the Internet, this identity
universe crashed. Suddenly, the primary goal of a Unix computer became
to serve information to strangers, and, worse, to take and process
information from strangers who could not be differentiated by the 
Unix process identity model, because the serving/receiving server process
had just one Unix identity, the "user id" it was started under. 

Due to the old convention of the non-admin users not being able to
start processes listening on TCP or UDP ports below 1024 -- which let
the users on a LAN distinguish between processes started by admins vs
other users (the former presumably more trustworthy or accountable) --
Internet servers were initially written to run as "root".  That meant
that any bug or diversion in their execution could be leveraged by
_any_ remote user to execute code as "root" -- that is, with the
ultimate privilege. BSD jails sought to contain that by limiting the
view of the filesystem to the process to the bare minimum of files,
but many ways were discovered to regain the full privilege ("break out
of jail").

Another reaction (sometimes used in conjunction with jailing) was to
run servers as the least-privileged user, "nobody". 

That worked so long as the servers served public and static files,
neither needing to take information (besides the requests) from users,
nor to distinguish between the views presented to users (the "internet
users" were all one for all intents and purposes). However, as soon as
per-user view differentiation and information storage became necessary
(e.g., in web-fronted databases or content management systems,
a.k.a. CMS), that model served no better; the "nobody" process was all
one to the other processes like the database server that it needed to
communicate with, and so those processes -- ostensibly less exposed
and thus coded even weaker than the public servers -- were no better
off. IPC was as bad for them as exposure to the Internet was for
servers running as root.

SELinux stepped in to limit the unlimited IPC and the unlimited access
of a process running-as-a-user too _all_ of user-owned files and
processes. Instead, it tied the identity and thus permitted operations
of a process to the file it was started from rather than the user it
was started under (for interactive user sessions, the user who signed
in and got the shell from which the process could be started; to
support this, servers would exit when started as a wrong user). 

This put Internet-facing servers into a "straight-jacket" specific to
every program (called "domain" or "type" in SELinux terms). Under
SELinux, a process started from /sbin/sshd (and so marked sshd_t)
could only access files marked for it, and the same was true for the
web server (marked httpd_t); IPC between processes was similarly
controlled.  Still, these lists of process-specific permissions are
long and not easy to manage -- keeping the right representation of a
process' identity and the corresponding parceling of privileges a
research question.

For a brief overview of SELinux, see slides 1-10 of
http://www.cs.dartmouth.edu/~sergey/ftc/secse07-slides-upd.pdf