public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: "Serge E. Hallyn" <serge.hallyn@canonical.com>
Cc: Eric Paris <eparis@redhat.com>,
	"Andrew G. Morgan" <morgan@kernel.org>,
	"Serge E. Hallyn" <serge@canonical.com>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH] System Wide Capability Bounding Set
Date: Fri, 28 Jan 2011 14:10:29 -0500	[thread overview]
Message-ID: <201101281410.29794.sgrubb@redhat.com> (raw)
In-Reply-To: <20110128184901.GA5134@localhost>

On Friday, January 28, 2011 01:49:01 pm Serge E. Hallyn wrote:
> > 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
> 
> Not sure I've got this.  Wrapper program in the VM he can over-write,
> but then he can overwrite the kernel too.

No, because the kernel is only read in at boot. After that, /boot can disapear and it 
won't matter. It can be replaced with something and that won't matter because that's 
not the real boot partition.

> But what we are worried about is the host, so you must mean that.  But if the
> wrapper program is of type noone_may_write_this_t, then wouldn't finding a way to
> replace that be as hard as overwriting the host kernel? 

No, because we aren't taking away the ability to mount or unmount. Not to mention that 
root can replace his selinux policy so that next boot it doesn't define 
noone_may_write_this_t. He might even put selinux in his VM in permissive.

> Which, of course, still remains as a viable attack vector for the guest admin,
> whether you have this bounding set or not.

No, with the bounding set, any external call the kernel makes has the bounding set 
applied. This means we don't have to further restrict root in unnatural ways.

> In other words, we have to accept that the TCB is always not just the
> kernel, but some user-space too.  And yes, the wrapper program here
> would be part of the TCB.

If you give someone root access in the VM, they probably want to set things up their 
way. So, we really would like it if all the security mechanism were inside where they 
can't be easily tampered with.

-Steve

  reply	other threads:[~2011-01-28 19:11 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 22:25 [PATCH] System Wide Capability Bounding Set Eric Paris
2011-01-06 11:30 ` Tetsuo Handa
2011-01-06 16:44   ` Theodore Tso
2011-01-11 22:02 ` Serge E. Hallyn
2011-01-11 22:12   ` Serge E. Hallyn
2011-01-14 19:50   ` Eric Paris
2011-01-17  3:16     ` Andrew G. Morgan
2011-01-21 21:25       ` Eric Paris
2011-01-23  3:39         ` Andrew G. Morgan
2011-01-24 21:40           ` Serge Hallyn
2011-01-26 23:34             ` Eric Paris
2011-01-27 14:02               ` Serge E. Hallyn
2011-01-27 14:42                 ` Steve Grubb
2011-01-27 16:43                   ` Andrew G. Morgan
     [not found]                   ` <AANLkTi=k5QeE_-iNuW3-M5K3BnBtRxk-QYO5624HKrpE@mail.gmail.com>
2011-01-27 16:50                     ` Steve Grubb
2011-01-28 18:19                       ` Eric Paris
2011-01-28 18:49                   ` Serge E. Hallyn
2011-01-28 19:10                     ` Steve Grubb [this message]
2011-01-28 19:38                       ` Serge E. Hallyn
2011-01-28 22:24                         ` Eric Paris
2011-02-01 18:17                         ` Eric Paris
2011-02-01 21:26                           ` Serge E. Hallyn
2011-02-02  4:02                             ` Andrew G. Morgan
2011-02-08  2:55                               ` Eric Paris
2011-02-14 20:45                                 ` Eric Paris
2011-02-14 21:24                                   ` Serge E. Hallyn
2011-02-18  0:29                                 ` Serge E. Hallyn
2011-01-27 14:26               ` Andrew G. Morgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201101281410.29794.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=serge.hallyn@canonical.com \
    --cc=serge@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox