From: Andy Lutomirski <luto@myrealbox.com>
To: Olaf Dietsche <olaf+list.linux-kernel@olafdietsche.de>
Cc: Chris Wright <chrisw@osdl.org>,
akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] capabilities, take 3 (Re: [PATCH] capabilites, take 2)
Date: Fri, 14 May 2004 07:15:56 -0700 [thread overview]
Message-ID: <40A4D49C.3030300@myrealbox.com> (raw)
In-Reply-To: <87d657z2lm.fsf@goat.bogus.local>
Olaf Dietsche wrote:
> Andy Lutomirski <luto@myrealbox.com> writes:
>
>
>>+ /* Pretend we have VFS capabilities */
>>+ cap_set_full(bprm->cap_inheritable);
>>+ if ((bprm->secflags & BINPRM_SEC_SETUID) && bprm->e_uid == 0)
>>+ cap_set_full(bprm->cap_permitted);
>>+ else
>>+ cap_clear(bprm->cap_permitted);
>
>
> I'd move this to security/commoncap.c:
[snip]
I put it in fs/exec.c because I had to add it to binprm anyway
(having commoncap use ->security would break SELinux), and, as
long as it's a permanent member of the structure, it made sense
for it to always be filled in.
>>+ /* FIXME: Is this overly harsh on setgid? */
>>+ if ((bprm->secflags & (BINPRM_SEC_SETUID | BINPRM_SEC_SETGID)) &&
>>+ new_pI != CAP_FULL_SET)
>>+ bprm->secflags |= BINPRM_SEC_NOELEVATE;
>>+
>>+ if (bprm->secflags & BINPRM_SEC_NOELEVATE) {
>>+ is_setuid = is_setgid = 0;
>>+ cap_clear(fP);
>>+ }
>
>
> This prevents sendmail from being setuid mail and
> cap_net_bind_service=ep.
AAAAH! That's right -- in my implementation <some cap>=ep on a file
makes no sense. It's got to be inheritable to be permitted.
On the other hand, that rule could be safely by checking the old pI
as opposed to the new one. The idea is to prevent a process without
full pI from execing (and thus confusing) old setuid apps.
BTW, in your capabilities implementation, why do you do:
# chcap cap_net_bind_service=ei /usr/sbin/named
# inhcaps cap_net_bind_service=i bind:bind /usr/sbin/named
It seems to me that this wants to be:
# inhcaps cap_net_bind_service=eip bind:bind /usr/sbin/named
(not having looked at your user tool)
or
# cap -c cap_net_bind_service=eip -u bind -g bind /usr/sbin/named
(using my tool)
With my patch, that just works (no fs caps necessary). Why should the
admin have to tag a program so it is allowed to inherit caps? (If
named used libexec, then its libexec helpers would have to be similarly
tagged, and, if it used bash, then bash would need the inheritable tag.)
If the answer's because that's how Linux cap evolution works, then
I'd say that Linux cap evolution is broken.
In any case, I'll probably redo my patch to restore the IRIX version of pI.
--Andy
>
> Regards, Olaf.
next prev parent reply other threads:[~2004-05-14 14:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-13 20:08 [PATCH] capabilites, take 2 Andy Lutomirski
2004-05-14 1:20 ` Chris Wright
2004-05-14 1:35 ` Valdis.Kletnieks
2004-05-14 4:51 ` Chris Wright
2004-05-14 5:33 ` Olaf Dietsche
2004-05-14 6:04 ` Valdis.Kletnieks
2004-05-14 7:09 ` Olaf Dietsche
2004-05-14 2:27 ` Andy Lutomirski
2004-05-14 4:48 ` Chris Wright
2004-05-14 5:58 ` Andy Lutomirski
2004-05-14 17:45 ` Chris Wright
2004-05-14 6:39 ` Olaf Dietsche
2004-05-14 2:45 ` [PATCH] capabilities, take 3 (Re: [PATCH] capabilites, take 2) Andy Lutomirski
2004-05-14 5:04 ` Chris Wright
2004-05-14 5:32 ` Valdis.Kletnieks
2004-05-14 5:40 ` Chris Wright
2004-05-14 6:25 ` Valdis.Kletnieks
2004-05-14 11:10 ` Olaf Dietsche
2004-05-14 14:15 ` Andy Lutomirski [this message]
2004-05-15 15:50 ` Olaf Dietsche
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=40A4D49C.3030300@myrealbox.com \
--to=luto@myrealbox.com \
--cc=akpm@osdl.org \
--cc=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olaf+list.linux-kernel@olafdietsche.de \
/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