Message-Id: <201101270942.07689.sgrubb@redhat.com>
Date:	Thu, 27 Jan 2011 09:42:07 -0500
From:	Steve Grubb <sgrubb@...hat.com>
To:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
Cc:	Eric Paris <eparis@...hat.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH] System Wide Capability Bounding Set

Hi Serge,

On Thursday, January 27, 2011 09:02:55 am Serge E. Hallyn wrote:
> What is the attack vector you're actually envisioning?  Does some
> trojan come in and overwrite a program which which it hopes the
> kernel will execute?  Or is there just an existing vuln in such
> a program?  Are there other ways we can address these?  Can we find
> a way to classify the kernel-spawned userspace programs?  Perhaps
> based on the selinux context assigned to the program, we can assign
> some level of trust that noone could have modified the source?


I think that what is causing the confusion is that we are considering a different 
threat model than the normal, historic view. The way its normally viewed, if you have 
root, you can do anything you want to a machine. The threat model revolves around 
becoming root on a machine and defense rests on splitting root so a complete system 
compromise might not occur.

Today, people want to have multi-tenant hosting using virtual machines whereby they 
give away root control of the guest VM. If you were renting system space, you would 
expect root access. That would make a nice juicy hacking target because you don't know 
who else is sharing the physical machine with you and they might have something in 
their VM worth stealing.

So, the threat model becomes how do we prevent one guest from attacking another? We 
have sVirt which prevents resource based attacks from occurring. Its pretty effective 
for that. However, what if the bad guy wants to start attacking the hypervisor 
directly in effort to start attacking the host OS? 

They need to be able to run arbitrary code in ring 0 of the VM. That means the hosting 
provider might want to eliminate some capabilities from the whole kernel so that they 
have some assurance that a root user cannot get arbitrary code running in ring 0 
without knowing a kernel level exploit. Also assume that the root user has no control 
over the kernel or modules or initrd which are kept on a read only partition enforced 
by the hypervisor. And the hosting provider will make kernel updates as kernel 
security releases are made.

This kind of turns around some of the threat modeling that people have always made. 
There are not a whole lot of changes that need to be made. I think there was one other 
patch that we needed to prevent arbitrary code injection. Eric's initial patch was 
overly generous in my opinion. It allowed further modification of the global bounding 
set after boot had finished and could probably be used for mischief as pointed out. 
Perhaps the setting should be immutable after any change to it - which is really how 
its intended to be used. Or maybe even only a subset of the bounding set is modifiable.

Using a wrapper program is a NOGO because the admin renting the machine would be able 
to overwrite the wrapper and then they have arbitrary code running with full privs and 
we trust it will do the right thing. We need all modification to the running kernel out 
of reach from root in that VM.

-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists