From: Andreas Gruenbacher <agruen@suse.de>
To: Dax Kelson <dax@gurulabs.com>, Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Olaf Dietsche <olaf.dietsche#list.linux-kernel@t-online.de>,
"Theodore Ts'o" <tytso@mit.edu>,
Rusty Russell <rusty@rustcorp.com.au>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"davej@suse.de" <davej@suse.de>
Subject: Re: [REPORT] current use of capabilities
Date: Tue, 5 Nov 2002 13:14:39 +0100 [thread overview]
Message-ID: <200211051314.39489.agruen@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0211021929040.20616-100000@mooru.gurulabs.com>
On Sunday 03 November 2002 04:36, Dax Kelson wrote:
> The principle of least privilege says that instead of a system full of
> binaries running as root, we should have a system of binaries running as
> non-root with only the capabilities they need.
>
> The typical break-in involves gaining non-root access first, then doing a
> privilege escalation attack to gain root. A system using capabilities
> makes the escalation attack must more difficult.
>
> How are we currently doing? The following (pathetically short list of)
> binaries use capabilities:
>
> vsftpd
> ntptimeset
> ntpdate
> ntpd
> named
>
> What are the potential users of capabilities?
>
> 47 SUID root binaries (EVERYTHING install of Red Hat Linux 8.0)
>
> Filesystem capabilities support could take care of these SUID root
> binaries. Historically, SUID root binaries have been heavily used in
> privilege escalation attacks.
>
> How about daemons that are launched as root? These could be potential
> users of capabilities + drop root right now.
>
> There is a snag though. When non-root binaries (eg, daemons running as
> non-root but with capabilities) execve(), all capabilities are cleared, so
> if some of these daemons need to exec other binaries with certain
> capabilities, it currently won't work.
>
> "ps aux | grep root" to take a look. We see stuff like:
>
> syslogd
> cardmgr
> apmd
> smartd
> xinetd
> dhclient
> gpm
> crond
> cupsd
> anacron
> rhnsd
> login
> mingetty
> X
>
> This is not an exhaustive list. The system I checked was not running many
> daemons.
>
> In summary, there is lots that could be done today to secure daemons. The
> clearing of capabilities on exec by non-root binaries needs be addressed
> (I posted a patch in May 2002). File system capabilities support can
> fix the large amount of SUID root binaries that exist. OpenBSD 3.2
> (just released) has started to implement a similar technique to get rid
> of SUID root binaries.
>
> Once filesystem capabilities is added to the kernel, RPM and DPKG should
> be fixed so that, otherwise SUID root binaries, can be installed with
> capabilities support automatically.
I agree that package managers should eventually be made aware of capabilities,
like they are now aware of file modes/ownership. There are several other
configuration issues to figure out that may depend on the overall purpose of
a system, like which user(s) are granted which capabilities when logging in,
checking the capabilities of installed binaries, etc.
> This should be the vendors / package maintainers job. The average sysadmin
> should get the benefits without having to think about it.
Yes.
--Andreas.
next prev parent reply other threads:[~2002-11-05 12:08 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-01 8:49 Rusty's Remarkably Unreliable List of Pending 2.6 Features Rusty Russell
2002-11-01 16:19 ` Karim Yaghmour
2002-11-02 6:32 ` Rusty Russell
2002-11-01 18:32 ` Filesystem Capabilities in 2.6? Dax Kelson
2002-11-01 19:05 ` Nicholas Wourms
2002-11-01 22:07 ` Olaf Dietsche
2002-11-01 23:25 ` Jan Harkes
2002-11-04 17:51 ` Mark H. Wood
2002-11-01 22:07 ` Olaf Dietsche
2002-11-01 22:59 ` Rusty Russell
2002-11-02 13:41 ` Olaf Dietsche
2002-11-02 7:06 ` Theodore Ts'o
2002-11-02 13:38 ` Olaf Dietsche
2002-11-02 18:18 ` Olaf Dietsche
2002-11-02 22:57 ` Bernd Eckenfels
2002-11-02 18:35 ` Dax Kelson
2002-11-06 1:07 ` Bill Davidsen
2002-11-02 18:47 ` Linus Torvalds
2002-11-02 23:02 ` Bernd Eckenfels
2002-11-02 23:11 ` Chris Wedgwood
2002-11-03 0:18 ` Rik van Riel
2002-11-03 0:22 ` Linus Torvalds
2002-11-03 0:43 ` Alexander Viro
2002-11-03 0:52 ` Alexander Viro
2002-11-04 13:02 ` Pavel Machek
2002-11-03 0:47 ` Rik van Riel
2002-11-03 1:53 ` Linus Torvalds
2002-11-03 1:05 ` David D. Hagood
2002-11-03 2:05 ` Linus Torvalds
2002-11-03 13:55 ` Olaf Dietsche
2002-11-05 8:47 ` Rogier Wolff
2002-11-05 10:50 ` Bernd Eckenfels
2002-11-03 1:27 ` Alan Cox
2002-11-03 2:43 ` Werner Almesberger
2002-11-03 12:46 ` Alan Cox
2002-11-03 0:56 ` Olaf Dietsche
2002-11-03 2:03 ` Linus Torvalds
2002-11-03 2:21 ` Alexander Viro
2002-11-03 3:23 ` Linus Torvalds
2002-11-03 3:35 ` Linus Torvalds
2002-11-03 4:28 ` Alexander Viro
2002-11-03 13:03 ` Alan Cox
2002-11-03 14:51 ` Alexander Viro
2002-11-03 16:50 ` Alan Cox
2002-11-03 16:56 ` Alexander Viro
2002-11-03 16:56 ` yodaiken
2002-11-03 18:13 ` Linus Torvalds
2002-11-03 18:25 ` yodaiken
2002-11-03 18:42 ` Linus Torvalds
2002-11-04 0:40 ` Rik van Riel
2002-11-03 7:36 ` Hacksaw
2002-11-03 8:59 ` Kai Henningsen
2002-11-03 10:50 ` Hacksaw
2002-11-04 8:55 ` Rando Christensen
2002-11-03 12:57 ` Alan Cox
2002-11-03 15:20 ` Bernd Eckenfels
2002-11-03 16:30 ` Ragnar Kjørstad
2002-11-03 16:40 ` Bernd Eckenfels
2002-11-03 17:10 ` Alan Cox
2002-11-09 20:11 ` Pavel Machek
2002-11-10 22:50 ` Bernd Eckenfels
2002-11-03 13:55 ` Olaf Dietsche
2002-11-03 3:50 ` Oliver Xymoron
2002-11-03 4:00 ` Dax Kelson
2002-11-03 4:10 ` Oliver Xymoron
2002-11-03 13:55 ` Olaf Dietsche
2002-11-03 4:20 ` Linus Torvalds
2002-11-03 4:37 ` Alexander Viro
2002-11-03 4:54 ` Linus Torvalds
2002-11-03 5:09 ` Alexander Viro
2002-11-03 5:39 ` Linus Torvalds
2002-11-03 6:37 ` Alexander Viro
2002-11-03 7:16 ` Dax Kelson
2002-11-03 9:18 ` Alexander Viro
2002-11-03 20:35 ` Michal Jaegermann
2002-11-04 9:25 ` Antti Salmela
2002-11-04 12:24 ` Olaf Dietsche
2002-11-04 14:39 ` Theodore Ts'o
2002-11-04 15:13 ` Jesse Pollard
2002-11-03 5:03 ` Oliver Xymoron
2002-11-03 5:25 ` Dax Kelson
2002-11-03 5:52 ` Linus Torvalds
2002-11-03 6:46 ` Alexander Viro
2002-11-03 12:53 ` Alan Cox
2002-11-03 13:52 ` Olaf Dietsche
2002-11-03 14:38 ` Alexander Viro
2002-11-03 16:01 ` Olaf Dietsche
2002-11-03 16:09 ` Alexander Viro
2002-11-03 12:51 ` Alan Cox
2002-11-03 21:02 ` Ryan Anderson
2002-11-03 3:36 ` [REPORT] current use of capabilities Dax Kelson
2002-11-03 13:57 ` Olaf Dietsche
2002-11-05 12:14 ` Andreas Gruenbacher [this message]
2002-11-03 4:04 ` Filesystem Capabilities in 2.6? Dax Kelson
2002-11-03 4:10 ` Alexander Viro
2002-11-03 5:31 ` Erik Andersen
2002-11-03 5:37 ` Dax Kelson
2002-11-03 5:42 ` Erik Andersen
2002-11-03 6:07 ` Dax Kelson
2002-11-03 22:24 ` Anders Gustafsson
2002-11-03 15:13 ` Bernd Eckenfels
2002-11-03 12:45 ` Alan Cox
2002-11-03 15:49 ` Patrick Finnegan
2002-11-04 15:00 ` Patrick Finnegan
2002-11-04 15:51 ` Olaf Dietsche
2002-11-04 16:53 ` Patrick Finnegan
2002-11-04 17:23 ` Olaf Dietsche
2002-11-03 13:30 ` Olaf Dietsche
2002-11-03 15:11 ` Bernd Eckenfels
2002-11-04 2:49 ` Jan Harkes
2002-11-04 14:50 ` Theodore Ts'o
2002-11-04 15:33 ` Alan Cox
2002-11-04 20:35 ` Ulrich Drepper
2002-11-04 21:50 ` Linus Torvalds
2002-11-04 14:58 ` Jesse Pollard
2002-11-05 23:47 ` Bill Davidsen
2002-11-06 13:36 ` Jesse Pollard
2002-11-05 4:14 ` Andreas Gruenbacher
2002-11-05 14:48 ` Olaf Dietsche
2002-11-05 15:05 ` Andreas Gruenbacher
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=200211051314.39489.agruen@suse.de \
--to=agruen@suse.de \
--cc=davej@suse.de \
--cc=dax@gurulabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf.dietsche#list.linux-kernel@t-online.de \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.com \
--cc=tytso@mit.edu \
--cc=viro@math.psu.edu \
/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.