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

Eric Paris
2011-02-06T16:51:35Z

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