Re: [PATCH] capabilities, take 3 (Re: [PATCH] capabilites, take 2)

[Andy Lutomirski]

Olaf Dietsche wrote:

> Andy Lutomirski <luto@xxxxxxxxxxxxx> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/