Re: request: capabilities that allow users to drop privileges further

[Felix von Leitner]

Thus spake Chris Wright (chrisw@xxxxxxxx):
> > I would like to be able to drop capabilities that every normal user has,
> > so that network servers can limit the impact of possible future security
> > problems further.  For example, I want my non-cgi web server to be able
> > to drop the capabilities to
> Using existing capabilities system you can limit many of these.

No.  The administrator can limit many of these.  I want the software to
be able to limit itself.

> Just dropping privs from uid = 0 to anything else is a good start.

If you give administrators tools to limit privileges, some well-educated
admins may do it, but the bulk will not.

If you give software authors the tools to drop privileges they don't
need, and you help everyone.

> >   * execve
> mount fs noexec

Not an option for a web server or smtpd.

> >   * ptrace
> drop CAP_SYS_PTRACE

That will still allow the process to ptrace other processes of the same
uid.

> >   * write to the file system
> mount fs r/o.

Again, not an option.

I hope I made myself more clear this time.

I would be happy with a well documented and fine grained capabilities
system, and maybe a new syscall:

  abstain(__NR_execve);

I would also like a way to say that I want to never access the network
except through sockets that are already open (and presumably passed to
me at process creation).  Dan Bernstein has a good rationale on what I
think is needed: http://cr.yp.to/unix/disablenetwork.html, however I
think if we do this, we might as well opt for more flexibility.

Imagine being able to call "gzip -dc" in a pipe and denying it write
access to the file system, network I/O and other harmful operations.
If programs can restrict themselves, we could write email client
software that uses external untrusted plugins without fear of buffer
overflows or catching yourself a root kit.

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