linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-mips@linux-mips.org, linuxppc-dev@ozlabs.org,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	sparclinux@vger.kernel.org,
	"Markus Gutschke \(?????????\)" <markus@google.com>,
	Nicholas Miell <nmiell@comcast.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Sun, 10 May 2009 07:37:01 +0200	[thread overview]
Message-ID: <20090510053700.GC1363@ucw.cz> (raw)
In-Reply-To: <20090507101129.GB5978@elte.hu>

On Thu 2009-05-07 12:11:29, Ingo Molnar wrote:
> 
> * Nicholas Miell <nmiell@comcast.net> wrote:
> 
> > On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (?????????) wrote:
> > > On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > > > doing a (per arch) bitmap of harmless syscalls and replacing the
> > > > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > > > pretty reasonable extension. (.config controllable perhaps, for
> > > > old-style-seccomp)
> > > >
> > > > It would probably be faster than the current loop over
> > > > mode1_syscalls[] as well.
> > > 
> > > This would be a great option to improve performance of our sandbox. I
> > > can detect the availability of the new kernel API dynamically, and
> > > then not intercept the bulk of the system calls. This would allow the
> > > sandbox to work both with existing and with newer kernels.
> > > 
> > > We'll post a kernel patch for discussion in the next few days,
> > > 
> > 
> > I suspect the correct thing to do would be to leave seccomp mode 1 
> > alone and introduce a mode 2 with a less restricted set of system 
> > calls -- the interface was designed to be extended in this way, 
> > after all.
> 
> Yes, that is what i alluded to above via the '.config controllable' 
> aspect.
> 
> Mode 2 could be implemented like this: extend prctl_set_seccomp() 
> with a bitmap pointer, and copy it to a per task seccomp context 
> structure.
> 
> a bitmap for 300 syscalls takes only about 40 bytes.
> 
> Please take care to implement nesting properly: if a seccomp context 
> does a seccomp call (which mode 2 could allow), then the resulting 
> bitmap should be the logical-AND of the parent and child bitmaps. 
> There's no reason why seccomp couldnt be used in hiearachy of 
> sandboxes, in a gradually less permissive fashion.

I don't think seccomp nesting (at kernel level) has any value.

First, syscalls are wrong level of abstraction for sandboxing. There
are multiple ways to read from file, for example.

If you wanted to do hierarchical sandboxes, asking your monitor to
restrict your seccomp mask would seem like a way to go...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2009-05-11 12:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090228030226.C0D34FC3DA@magilla.sf.frob.com>
     [not found] ` <20090228030413.5B915FC3DA@magilla.sf.frob.com>
     [not found]   ` <alpine.LFD.2.00.0902271932520.3111@localhost.localdomain>
     [not found]     ` <alpine.LFD.2.00.0902271948570.3111@localhost.localdomain>
2009-02-28  7:25       ` [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Roland McGrath
2009-02-28  7:31         ` Ingo Molnar
2009-02-28  7:36           ` Roland McGrath
2009-02-28 17:23         ` Linus Torvalds
2009-02-28 17:46           ` [stable] " Greg KH
2009-02-28 17:54             ` Arjan van de Ven
2009-02-28 18:23               ` Greg KH
2009-02-28 20:27                 ` Greg KH
2009-02-28 21:09           ` Benjamin Herrenschmidt
2009-03-02  1:44           ` Roland McGrath
2009-05-06 18:42           ` Markus Gutschke
2009-05-06 18:46           ` Markus Gutschke (顧孟勤)
2009-05-06 21:29             ` Ingo Molnar
2009-05-06 21:46               ` Markus Gutschke (顧孟勤)
2009-05-06 21:54                 ` Ingo Molnar
2009-05-06 22:08                   ` Markus Gutschke (顧孟勤)
2009-05-06 22:13                     ` Ingo Molnar
2009-05-06 22:21                       ` Markus Gutschke (顧孟勤)
2009-05-07  4:23                         ` Nicholas Miell
2009-05-07 10:11                           ` Ingo Molnar
2009-05-10  5:37                             ` Pavel Machek [this message]
2009-05-08 19:18                     ` Andi Kleen
2009-05-07  7:03                 ` Roland McGrath
2009-05-07  8:01                   ` Markus Gutschke (顧孟勤)
2009-05-07  7:30                 ` Roland McGrath
2009-05-07  7:31                 ` Roland McGrath

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=20090510053700.GC1363@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=markus@google.com \
    --cc=mingo@elte.hu \
    --cc=nmiell@comcast.net \
    --cc=roland@redhat.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).