[CentOS] SELinux threads, cynicism, one-upmanship, etc.

[Les Mikesell]

On Fri, 2005-11-18 at 21:29, Lamar Owen wrote:

> > > What is the most critical injury on academic networks today?  Think about
> > > it a while, as it's not what you think; but rooting a box has a lot to do
> > > with it, and it's on the inside network typically.
> 
> > Unless its different than every other network, it's windows boxes
> > loaded with spyware and spam-sending zombies.
> 
> Yes, this is correct.  What are the lessons a Linux admin can learn from the 
> Windows malware scourges, some of which don't require you to be running as an 
> administrator-equivalent?

My take on it is that windows has crammed so much code and policy
into the kernel and programs that must run as administrator that
they will never be able to get all the bugs out.  The lesson to
learn - and the one that worked for unix the last 30 years - is to
keep the kernel simple with simple, well understood mechanisms, and
keep complex policy out of there.

> If anything, the spyware/zombie scourge should be the driving force behind 
> SELinux adoption to prevent the same thing from happening to the Linux boxes 
> (a well-place root hole and a linux-aware Windows spyware/worm, and your 
> Linux box is owned from the inside).

Or not, depending on how you interpret the problem.  You don't see
spyware infested Centos 3.x boxes, and you don't see people afraid
to keep them updated because updates routinely break their apps.

> Is it too far of a leap to want to nip 
> the coming scourge in the bud?  Linux boxes are not immune as long as root 
> holes exist that can leverage root's superuser powers, unfettered by role 
> based and mandatory access controls. 

And you reduce/eliminate those holes by keeping the code simple
and well-understood.

> If there is no superuser in the 
> traditional sense, the root hole is useless.  Completely useless.

That's a separate issue, not really changed by adding more
complexity in the kernel where the code can do anything.

> You might think I'm paranoid; the black hats are indeed this devious and are 
> indeed using devices like this today.  If SELinux can help plug a few cracks, 
> then it's worth learning and using.

You aren't paranoid enough.  Worry about SELinux adding cracks, making
the kernel more complicated, and less understood - having unexpected
side effects that someone will learn to exploit.  Or explain why this
is impossible so I can share your confidence.  

> I have had the experience of having a box get a rootkit; it is not a pleasant 
> experience, and taught me a valuable lesson.  Yes, the box had a firewall in 
> front of it.  No, it didn't help.  While it was back in 1998, it is a lesson 
> I will never forget.

But do you think the bugs can't be in the kernel itself?

> The investigators who contacted me afterwards told me that this particular 
> incident involved over 20,000 hosts, all compromised in the space of 14 
> hours.

Yes, this is what happens when everyone uses the same code, and this
code wasn't even in your kernel.

>   Scripted, using a BIND root hole.  Hit my public DNS server; used 
> carefully crafted packets on TCP port 53 for remote root shell.  Happened 
> before the patch was available for BIND.  Happened before chrooted BIND was 
> commonly available.  The first file they transferred out was /etc/shadow.  
>
> The only common advice used today that would have thwarted that exploit was 
> running BIND chrooted.

The mechanism was there all along, the policy wasn't - and the policy
didn't belong in the kernel.

-- 
  Les Mikesell
    lesmikesell at gmail.com