Re: [PATCH] System Wide Capability Bounding Set

[Andrew G. Morgan]

[Resend because of bounces.]

On Thu, Jan 27, 2011 at 6:42 AM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
> 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?

Which root filesystem (/) do kernel helpers run in in such a setup? I
would have expected that they occurred in the hypervisor where the
selection of helper binaries would be outside the control of the
guests. Is this not the case?

Thanks

Andrew

>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/