Messages in this thread | | | Date | Tue, 18 May 1999 07:50:49 -0400 | From | John Wojtowicz <> | Subject | Re: More capabilities stuff... |
| |
Albert D. Cahalan wrote:
> >>> 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/
| |