Re: Using ftrace/perf as a basis for generic seccomp

[Eric Paris]

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

--
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/