> >>> On Sun, 16 May 1999, Albert D. Cahalan wrote:
> >
> > That by definition isn't a privilege.
>
> Sure it is. You don't think of it as one because it is normally given
> to every user, but it is a privilege. Opening a network connection is
> a privilege. Debugging your own process is a privilege.
I stand corrected. Actually a few privileges in Trusted Solaris are
actually
more "functional" than "security policy". And these never mapped to root
privileges.
>
>
> It would be very good to take away the right to exec() privileged
> executables, so that a cracker with a shell could not attack buggy
> privileged executables in the normal manner.
You can take care of this sort of problem with inheritable privileges.
A good privileged program will lower inheritable privs and only raise
them if it plans to exec() a program that needs them. If it never
expects to exec any other program, you drop them from the permitted
set as well. That way you can never re-raise them. If an exec happens
because of shell code the inheritable privs aren't raised and the shell
gets no privs, (with the exception of programs have forced privs, which
always get them. But any added security helps, so this privilege
(CAP_EXEC?)
you mention would probably be a good thing.
>
> This is what Linux 2.2 already does, except that all users get a full
> set of inheritable bits.
Great!
John
-- John Wojtowicz, Secure Systems Engineer jwojtowicz@tcs-sec.com Trusted Computer Solutions wojtowij@erols.com Herndon, VA 20171
- 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/