Messages in this thread | | | Date | Fri, 23 Apr 1999 10:56:34 -0700 (PDT) | From | Y2K <> | Subject | Re: file effective and process inheritable mask |
| |
On Fri, 23 Apr 1999, David L. Parsley (lkml account) wrote: > On Fri, 23 Apr 1999, Albert D. Cahalan wrote: > > David L. Parsley writes: > > smart fE should be empty > why not pE=pP initially, and let the 'smart' program continue to > manipulate pE as it desires? If they are smart then they should code like this: { /* to use syscalls that need more privledges */ if (security_policy_checks_ok() ) { raise_effective_caps(caps_I_need_right_now); do_special_thingie(); drop_all_effective_caps(); } else freak_out(); }
{ /* forking and execing */ cap_t new_pI; if (!fork() ) { new_pI=current_pI¤t_pP&(CAP_FOO | ... | CAP_BAR); /* only what needed */ set_new_pI(new_pI); execve(...); } }
main should be written like: int main(void) { drop_all_effective_caps(); if (main_security_policy_bad() ) { printf("You bad man-- stranger\n"); return OH_MY_GOD; } /* now with our regular scheduled program */ }
> > > Two, (and I'm thinking mostly here about non-cap-aware binaries), > > > it seems like it would be nice to be able to constrain the passage of the > > > inheritable set using our cap-elf model. I'm referring to an fM, where it > > > masks off bits in the inheritable by the formula pI' = pI && fM. This > > > occurs to me after thinking about an admin account starting a program by > > > hand, where the shell might have a mostly full inheritable set. This > > > seems like a bad security issue, since that program can exec() another > > > program with a more potent inheritable set. Don't use SECURE_CAP_PURE then. I think it is broken anyway. > > Think of it being a bit like the > > ability to run a normal setuid-root executable. Normal users are allowed > > to do that. It would be silly to only let already-privileged users run > > privileged executables. Yes it is silly and broken. > Right, but 'more' has no business having CAP_SETFCAP in it's pI under > _any_ circumstances. (well, none legitimate that I can think of) So > having CAP_SETFCAP in it's pI is a pretty big priviledge that we currently > have no good method for removing. Like Pavel has said that is easy for 'more' with elf header's it all then other guys stuff you gotta worry about. > > 1. The ability to mark an executable with the minimum capabilities > > needed to properly execute. This helps avoid crashes. > > Well, I've tried to illustrate a broad class of problems that appear to > require the solution I've suggested. I can certainly _see_ what you're > talking about here, but I can't think of any good examples that would > cause any real problems. If this is really a corner case you're talking > about here, it may be best solved in other ways (patching the program, > since not error-checking is an obvious bug). I'm just thinking it's not > efficient to store this extra info if <1% of cap-enabled programs really > need it. On the other hand, the abscence of fM seems to require patching > a _lot_ of programs to make them capability-aware. Yes cause its not backwards compatible and IMHO broken. > OK, this 'future-proofing' is something I haven't really given much > thought to, but I can see how it could become an issue. I'll try to think > about this today some. You can reserve a range of numbers. > Well, I can see the need for quite a few files in /proc/... to tune > default behavior; and this is fairly cheap. It should probably be done by mount point.
PS I latest patch supports "pure" caps now by setting via securebits mechanisms, even though I think it is broken.
-- Warning when I mention capabilites I mean "soiled" capabilities not "pure". Any caps I mention are *derived* from a withdrawn draft posix document.
- 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/
| |