From: "Serge E. Hallyn" <serge@hallyn.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Wondering: why capabilities system is broken?
Date: Tue, 17 Apr 2007 20:57:29 -0500 [thread overview]
Message-ID: <20070418015728.GA20727@vino.hallyn.com> (raw)
In-Reply-To: <46252471.2030006@tls.msk.ru>
Quoting Michael Tokarev (mjt@tls.msk.ru):
> Hopefully not a flamewar question...
nothing wrong with asking for clarification. Though you should have
copied linux-security-module@vger.kernel.org.
> Currently, capabilities of a process are reset during exec()
> system call. At least effective+permitted set.
>
> 1) In case new uid != 0, all the caps are cleared, so it is not
> possible to execute a program as non-root but still give it some
> capabilities (like, say, CAP_NET_BIND_SERVICE).
With the introduction of file capabilities in -mm, you can assign
CAP_NET_BIND_SERVICE to a program not owned by root such that all users
can run the program with that capabilities.
Even in mainline, you can make the program setuid 0 and code it such
that it immediately specify keepcaps, change to nonroot, and drop all
caps but CAP_NET_BIND_SERVICE.
> 2) In case new uid == 0, effective and permitted sets are restored
> to all-ones.
>
> This is regardless of other settings, like prctl(KEEPCAPS), or
> the current set of capabilities.
Look at the prctl(2) manpage - it is about keeping capabilities across
setuid, not across exec.
> I partly understand why 2) is done - in case of setuid binary being
> executed, all the capabilities are set for it. But this breaks
> executing non-setuid binaries too -- for example, it'd be very nice
> to be able to chroot to some directory, and remove CAP_SYS_CHROOT
> (and other evil caps like CAP_SYS_MODULE, CAP_SETPCAP) -- this way,
> with minimal efforts, chroot will work almost (yes, I understand
> it's not entirely the same) the same as BSD jail(2) concept.
Are you aware of the namespace/containers work going on right now to get
full virtual server support into mainline? See
http://lists.linux-foundation.org/pipermail/containers/
for the archives of the main relevant mailing list.
> So the question is: why capability sets are being reinitialized during
> exec()? At least in 2.4 era, they weren't... and stuff like
> execcap, sucaps etc was working. Now they aren't anymore.
Please see the file capabilities support in -mm and let us know whether
that does (not) meet your needs.
thanks,
-serge
prev parent reply other threads:[~2007-04-18 1:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-17 19:48 Michael Tokarev
2007-04-18 1:57 ` Serge E. Hallyn [this message]
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=20070418015728.GA20727@vino.hallyn.com \
--to=serge@hallyn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjt@tls.msk.ru \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®