Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: file effective and process inheritable mask | Date | Sun, 25 Apr 1999 02:53:20 -0400 (EDT) |
| |
David L. Parsley writes: > On Fri, 23 Apr 1999, Albert D. Cahalan wrote: >> David L. Parsley writes: >>> 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? >> >> This is a poor design because the smart program must clear pE as soon >> as possible. If C++ is used, main() might not even be the first code >> to execute. There may be security holes in global constructors. > > Aarrgghh. Yes, I see your point; it just seems like a shame to tack this > extra set on all cap-enabled binaries just to support your odd C++ > cap-enabled. Since a set is 128 bits, and I hope we never use them all, > maybe we could steal a high-order bit to say raise/lower all effective?
Why bother? It is only 16 bytes. Look at these:
-rwxr-xr-x 1 root root 1089889 Jul 8 1998 bash -rwxr-xr-x 1 root root 138812 Jan 10 1998 gawk -rwxr-xr-x 1 root root 580716 Jul 1 1998 rpm -rwxr-xr-x 1 root root 257212 Jan 10 1998 tcsh -rwxr-xr-x 1 root root 294812 Jan 10 1998 vim
That is just the /bin directory. There are some real treasures in /usr/bin and /usr/X11/bin, including a 3186694-byte monster.
(remember, those 16 bytes are only needed when loading the executable)
Bit stealing is ugly. For only 0.01% to 0.1% savings, no thanks.
>>>>> 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. >>>> >>>> You are supposed to be able to do that. >>> >>> Certainly! That's the whole point of the way inheritable passes between >>> processes. I'm just saying that, in looking at designing a secure system >>> around caps, there are many cases where I _don't_ want inheritance to pass >>> in the usual fashion. Some programs just have no business exec'ing >>> another process and giving it elevated privs. Running named, mountd, >>> imapd, portmap, etc with pI=(mostly full) makes them just as vulnerable to >>> buffer overflow exploits as before; i.e., they could exec /bin/sh and get >>> a shell with mostly raised pI=='root shell'. So by including an fM, I can >>> prevent programs from getting a full pI when they don't need it. This, >>> IMHO, is perfectly in line with the principle of least priviledge. >> >> I don't think this is useful. Consider this: >> >> 1. If an attacker can cause an exec(), the attacker most likely >> has gained full control via a buffer overflow. > > Exactly. Now ask yourself; if the attacker decides to 'exec /sbin/sh', do > you want pI=(mostly full)=='root shell' or pI=(only what the program > needed)=rather crippled. One useful bit of information from the POSIX > spec: a process cannot raise a bit in the inheritable set that is not > already set in permitted. So, my extension would allow, in many cases, > pI=pP=(one or two caps) - still dangerous, but much less than before.
OK, this seems useful.
>>>> Besides confusion and tech support trouble, crashes can allow DoS attacks >>>> and possibly worse. >>>> >>>> The two most important extensions IMHO are: >>>> >>>> 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 >> >> I don't want to find out if this is a corner case, do you? We'd know >> it is not a corner case if we see a security alert go out. >> >> I could think up some odd kind of DoS attack, but it would be better >> if someone would post a real example. There have been attacks that >> used the CPU time and file size limits. > > I'm just not willing to entertain extensions to prevent a measly DoS > attack (which I grant can be bad, but less catastrophic that root shells) > that adds extra space and calculation overhead for everbody when we > currently can't think of a good example. And if you _do_ think of one or > two examples, we'll have to decide whether they are general enough to > warrant the extension, or whether the code should just be patched.
The nice error messages are almost enough reason alone. With the additional possibility of a DoS attack, I think the cost is justified.
- 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/
| |