Re: file effective and process inheritable mask

Y2K (y2k@y2ker.com)
Fri, 23 Apr 1999 10:56:34 -0700 (PDT)

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&current_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/