All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix von Leitner <felix-kernel@fefe.de>
To: Chris Wright <chrisw@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: request: capabilities that allow users to drop privileges further
Date: Wed, 17 Dec 2003 02:30:08 +0100	[thread overview]
Message-ID: <20031217013008.GA8571@codeblau.de> (raw)
In-Reply-To: <20031215144809.A14552@osdlab.pdx.osdl.net>

Thus spake Chris Wright (chrisw@osdl.org):
> > 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

  parent reply	other threads:[~2003-12-17  1:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-15 21:39 request: capabilities that allow users to drop privileges further Felix von Leitner
2003-12-15 22:10 ` Richard B. Johnson
2003-12-15 22:55   ` Christian Borntraeger
2003-12-16 14:08   ` Martin Waitz
2003-12-15 22:34 ` Christian Borntraeger
2003-12-15 22:48 ` Chris Wright
2003-12-16 14:13   ` Martin Waitz
2003-12-17  1:30   ` Felix von Leitner [this message]
2003-12-17  1:41     ` Chris Wright
2003-12-16 13:27 ` James Morris

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=20031217013008.GA8571@codeblau.de \
    --to=felix-kernel@fefe.de \
    --cc=chrisw@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.