[lkml]   [2011]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


 \ /
  Last update: 2011-01-27 15:45    [W:0.095 / U:0.464 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site