LKML Archive on
help / color / mirror / Atom feed
From: Eric Paris <>
To: Stefan Fritsch <>
Subject: Re: Using ftrace/perf as a basis for generic seccomp
Date: Sun, 06 Feb 2011 11:51:02 -0500	[thread overview]
Message-ID: <1297011064.2530.17.camel@localhost.localdomain> (raw)
In-Reply-To: <>

Dropped a lot of people and added 2 more.  I'm going to try to shift the
direction of this thread to discuss how to handle suid apps in a
potential sandbox solution (and remember, I don't consider an extended
seccomp to be a sandbox, it's just a tool to help create a sandbox)

Stefan would like to be able to prevent SETUID programs and programs
with fcaps from executing.  I suggested (below) that he play with prctl,
drop things from bset, pP, pE, pI, and then remove the suid(2) syscall
from the set of allowed syscalls.  He had some concerns:

On Sat, 2011-02-05 at 12:42 +0100, Stefan Fritsch wrote:
> On Fri, 4 Feb 2011, Eric Paris wrote:
> > On Thu, 2011-02-03 at 23:06 +0100, Stefan Fritsch wrote:

> >> - deny exec of setuid/setgid binaries
> >> - deny exec of binaries with filesystem capabilities
> >
> > I think both of these are wrong to try to address here.  The right way
> > to handle these is to
> >
> > 1) set prctl(SECBIT_NOROOT)
> > 2) drop all caps from the bset, pP, pE, and pI
> > 3) make sure the setuid(2) syscall (not to be confused with SETUID
> > filesystem bit) is not in the set of allowed syscalls.  Thus rendering
> > suid and file with fcaps irrelevant.
> I think that's a bad idea. Some programs may get confused if run as root 
> but without capabilities (think sendmail). If a setuid root binary gets 
> confused enough to write arbitrary files as root, you get all capabilities 
> again by writing to /etc/crontab or /root/.ssh/authorized_keys. I admit 
> that this is very unlikely if setuid(2)/setgid(2) lead to the process 
> being killed, but better to be save and disallow the user change for 
> SETUID binaries completely. And the simplest way to do that seemed to me 
> to disallow exec'ing of SETUID binaries.

I believe that my method should be safe for fcaps.  I believe the fcaps
code will kill any process that is unable to get the caps it claims to
need.  But I believe he's right about SUID apps with SECBIT_NOROOT.
sendmail (unless it was smart) wouldn't know it didn't have permissions
to do what it needed to do and would thus, likely break.  Anyone have
thoughts on that?  I've thought a couple of times about adding a new LSM
hook security_exec_suid() which would just be a big hammer blocking the
execution of suid root files.  How can we safely and sanely prevent the
execution of suid root files?


      reply	other threads:[~2011-02-06 16:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12 21:28 Eric Paris
2011-02-01 14:58 ` Eric Paris
2011-02-02 12:14   ` Masami Hiramatsu
2011-02-02 12:26     ` Ingo Molnar
2011-02-02 16:45       ` Eric Paris
2011-02-02 17:55         ` Ingo Molnar
2011-02-02 18:17           ` Steven Rostedt
2011-02-03 19:06         ` Frederic Weisbecker
2011-02-03 19:18           ` Frederic Weisbecker
2011-02-03 22:06           ` Stefan Fritsch
2011-02-03 23:10             ` Frederic Weisbecker
2011-02-04  1:50               ` Eric Paris
2011-02-04 14:31                 ` Peter Zijlstra
2011-02-04 16:29                   ` Eric Paris
2011-02-04 17:04                     ` Frederic Weisbecker
2011-02-05 11:51                       ` Stefan Fritsch
2011-02-07 12:26                         ` Peter Zijlstra
2011-02-04 16:36             ` Eric Paris
2011-02-05 11:42               ` Stefan Fritsch
2011-02-06 16:51                 ` Eric Paris [this message]

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:

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

  git send-email \
    --in-reply-to=1297011064.2530.17.camel@localhost.localdomain \ \ \ \ \ \
    --subject='Re: Using ftrace/perf as a basis for generic seccomp' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).