LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Stefan Fritsch <sf@sfritsch.de>
Cc: linux-kernel@vger.kernel.org, morgan@kernel.org, serge@canonical.com
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: <alpine.DEB.1.10.1102051226110.26628@eru.sfritsch.de>

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?

-Eric


      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:
  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=1297011064.2530.17.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morgan@kernel.org \
    --cc=serge@canonical.com \
    --cc=sf@sfritsch.de \
    --subject='Re: Using ftrace/perf as a basis for generic seccomp' \
    /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

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