On Sun, 2008-11-02 at 02:41 +0000, Lisa Kachold wrote:

> > I think that the three come down to what are your goals. One of the
> > goals of SELinux is to make it so that it can be configured to the
> point
> > of not having a root user. 
> 
> The goal of SELinux is to limit binary processes to files.
> 
> Reference:
> http://www.usenix.org/events/sec03/tech/full_papers/jaeger/jaeger_html/node2.html
> 
> It has nothing to do with root users, or permissions for users other
> than it provides an object framework upon them.
> 
> SELinux is a wrapper OVER root users, regular process permissions.
> 
> Reference:
> http://packages.debian.org/etch/selinux-policy-refpolicy-targeted

Yes exactly.  So effectively you make it so that user zero doesn't
control all.  Not that the user doesn't exist per se, but so that they
can't do what ever they want.  That's what I was trying to say, of
course you can always have a user zero -- it may just be that user 100
has the most authorization in the system.

> > Basically so the IT guy can't read the
> > president's e-mail. This is very cool if you need that level of
> > security -- but I'm guessing you're not sending nuclear launch codes
> (or
> > at least I hope not). The problem comes down to, with flexibility
> and
> > power you definitely have enough rope to shoot yourself in the foot.
> 
> Negative - the IT guy CAN STILL read the president's email if he has
> server access and permissions.
> 
> Reference:  http://whitepapers.zdnet.com/abstract.aspx?docid=286306
> 
> I know of no SELinux policy that excludes root or IT access from
> reading email.

Well SELinux is implemented based on the Redbook specification (I forget
what it's called now) by the NSA -- which specifically has this goal.
I've never see a policy set up this way either, but I'm guessing that
the default install at the NSA has something different than default
Fedora :)

> [Irregardless - the IT staff generally can sniff network packets and
> payloads therefore they can read all SMTP which is CLEAR TEXT
> transmissions anyway...]

Of course, security is a system problem.  One would hope that someone
smart enough to set up a comprehensive security system based on SELinux
wouldn't send e-mail payloads in the clear.  But one would think that
they wouldn't redact documents with black squares leaving the text in
the PDF also...

> > I've talked with the folks implementing AppArmor in Ubuntu a lot
> about
> > this, and one of the problems that we saw is that almost any Fedora
> > HOWTO on the Internet starts with "disable SELinux." I'm not sure
> how
> > many Fedora systems have it running and how many don't, but I'm
> guessing
> > that a fair number don't because of this. Not good.
> 
> During build, it's appropriate to disable SELinux, then run the Wizard
> or setup your policy once your server is setup.

The problem is that most of the HOWTOs simply didn't do this.  It was
things like "configure Apache to do SSL" and the first thing they did
was remove SELinux.  I'm not saying they were correct, I'm saying that's
what they did.

> Evidently you have not read through nor implemented either SELinux or
> Apparmour (these are standard tasks).

That's a touch harsh.  Especially considering I was talking about HOWTOs
on the Internet.

> > I think an interesting example of using AppArmor is the new guest
> > account feature in Intrepid. We basically dynamicly create an
> account
> > and lock it down with AppArmor to make sure that the guest can't do
> > anything crazy.
> 
> That is a standard policy in AppArmor, not Intrepid.

Well, we've made the guest account more restrictive than standard
accounts.  If you'd like to investigate further you can grab an Intrepid
live CD and look at:

    /etc/apparmor.d/gdm-guest-session


Another thing that was not mentioned in this thread but is important to
anyone looking to lockdown a system with GUI users on it is PolicyKit.
PolicyKit restricts specific DBus actions for users.  Typically this is
things like, if you're not logged in at the console you can't shutdown
the machine.  I'm not aware of any handy guides for locking this down
further in multi-user environments, but I'm sure that it should at least
be reviewed.

		--Ted