Re: updated proposal for cap in elf
Y2K (y2k@y2ker.com)
Sun, 18 Apr 1999 20:32:39 -0700 (PDT)
On Sat, 17 Apr 1999, Albert D. Cahalan wrote:
> > pI' = pI
> > pP' = fP | ( fI & pI & pP)
> > pE' = fE & pP'
> No, this is bad. Consider an admin with the bits below. Normal users
> on this system don't get any bits set, unlike the current default.
> pI == 00000000fffffeff
> pP == 0000000000000000
I would think pP should be pP == 00000000fffffeff
> pE == 0000000000000000
pE should maybe be a little higher so that some of the shell builtins work
like echo 'foo' >> /etc/passwd still work ;->
> The admin is only allowed to do his work via tools that leave an
> audit trail, so his shell only has the above. The shell can't do
> anything at all.
Auditing would be more reliable on a per sys-call basis IMHO.
Especially since for legacy situations mv does no inherent logging.
Also I think that shell builtins should work if they still need some caps.
> The /bin/mv executable has bits set in fI. Normal users should not
> get any special rights when they run /bin/mv, but the admin should
> gets a few capability bits in pP when running it.
Yes in the old formula it would be 00fffffeff using old formula and your
numbers -- I consider that a bug you a feature. Under my system normals
don't get special rights, but enhanced users would be able to use caps
even in his shell builtins or legacy programs.
Under my system he would get his powers in pP' because his old pP had the
power and it didn't get masked out. Normals would not have had the cap in
their pP.
> For /bin/mv, the bits are:
>
> fI == 00000000fffffeff
> fP == 0000000000000000
> fE == 0000000000000000
For backwards compatibility fE would have to be non-zero.
Since mv doesn't do many network stuff or change uid, etc it should set
its fI much lower hypothetically 0e4a .
fP should be zero.
> Your system would not give /bin/mv the capabilities it needs to have.
> I think you were expecting that pP would contain something, and that
> a normal user would have bits set in pI. These are bad assumptions.
Yes pP should be what that process and what its children might need
inherite. Normals may or may not have a non zero pI I'd think it would
start out to be somewhat high.
> In the "pP' = fP | (fI & pI)" expression you can see that the admin
> gets power from the "(fI & pI)" part, while normal users can only get
> power from the "fP" part. All of the admin's special rights are stored
> in the pI value, since the other values do not even influence an exec().
What about the situation where a user calls a legacy program that was suid
root but now gains stuff from fP but it does some of its work by calling
other programs that still need those privledges?
I don't think anybody should gain power from fI only from pP(heavily
masked by inheritance flags) or fP. It sounds like your pI is a
quazi-permitted bit. I can't do it but this indicates that maybe one of my
children will say I can whereas if not then I could not use it.
> No, we need a set of bits (I'll call it "pm") that are always added to pP.
> The set would be 0 for maximum security or normal users, and ~0 for an
> admin on a more normal system. This might be help kill off the ugly hack
> in exec.c that pretends an executable has fI and fE full if UID 0 runs it.
What you call pm I call pI & pP which then gets further masked by fI.
What would you have for defaults on trusted marked binaries? untrusted
marked ones?
>
> new_pP = fP | (fI & old_pI) | old_pm;
> if(new_pP & ~old_pM) return -EPERM; /* getting prohibited caps? */
Why are you getting prohibited caps thats why there is fI?
> if((new_pP & fm) != fm) return -EPERM; /* not enough? */
That I can see as being potentialy useful.
Anyway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/