From: Andy Lutomirski <luto@myrealbox.com>
To: Andrew Morton <akpm@osdl.org>
Cc: chrisw@osdl.org, linux-kernel@vger.kernel.org, luto@myrealbox.com
Subject: Re: [PATCH 0/2] capabilities
Date: Wed, 12 May 2004 18:50:01 -0700 [thread overview]
Message-ID: <40A2D449.7090103@myrealbox.com> (raw)
In-Reply-To: <20040512164132.2d30dac2.akpm@osdl.org>
Andrew Morton wrote:
> Andy Lutomirski <luto@myrealbox.com> wrote:
>
>>This reintroduces useful capabilities.
>>
>
>
> What if there are existing applications which are deliberately or
> inadvertently relying upon the current behaviour? That seems unlikely, but
> the consequences are gruesome.
Like something that turns KEEPCAPS on then setuid()s then executes an
untrusted program? It's obviously wrong, but it's secure currently
since the exec wipes capabilities. And no one would notice. Ugh!
>
> If I'm right in this concern, the fixed behaviour should be opt-in. That
> could be via a new prctl() thingy but I think it would be better to do it
> via a kernel boot parameter. Because long-term we should have the fixed
> semantics and we should not be making people change userspace for some
> transient 2.6-only kernel behaviour.
The prctl would defeat the purpose (imagine if bash forgot the prctl --
then the whole thing is pointless). I'll cook up the boot parameter in
the next couple days (probably with a config option and some kind of
warning that the old behavior is deprecated). Is it a problem if I make
the changes to init's state unconditional? (I still don't see why
CAP_SETPCAP is dangerous for root to have...)
The only concern is that some new code relies on the new inheritable
semantics. That shouldn't be so bad, though, since that's just an extra
precaution (if there are insecure setuid binaries around, you already
have problems).
--Andy
next prev parent reply other threads:[~2004-05-13 1:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-12 3:24 Andy Lutomirski
2004-05-12 3:44 ` Chris Wright
2004-05-12 23:41 ` Andrew Morton
2004-05-13 1:50 ` Andy Lutomirski [this message]
2004-05-13 1:55 ` Andrew Morton
2004-05-15 0:00 ` Paul Jakma
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=40A2D449.7090103@myrealbox.com \
--to=luto@myrealbox.com \
--cc=akpm@osdl.org \
--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 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®