lkml.org 
[lkml]   [1999]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: file effective and process inheritable mask
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.052 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site