Messages in this thread | | | Date | Sun, 18 Apr 1999 20:32:39 -0700 (PDT) | From | Y2K <> | Subject | Re: updated proposal for cap in elf |
| |
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/
| |