Re: caps in elf, next itteration (the hack get's bigger)

Albert D. Cahalan (acahalan@cs.uml.edu)
Wed, 21 Apr 1999 13:37:57 -0400 (EDT)


Andrej Presern writes:
> On Sat, 17 Apr 1999, Albert D. Cahalan wrote:
>> David L. Parsley writes:
>>> On Fri, 16 Apr 1999, Andrej Presern wrote:
>>
>>>> [...] marginal security gained by 'turning off' a capability in the
>>>> 'effective' set but leaving it 'on' in the 'permitted' set is exactly
>>>> zero, making the set of permitted capabilities effectively the set of
>>>> effective capabilities. In other words, your process is either able
>>>> to do something, or not able to do something - an extra syscall or
>>>> two makes no difference.
...
>> Andrej Presern seems to view security in a very mathematical way, without
>> concern for stupid human errors.
>
> Bugs (you may call them stupid human errors if you like, I prefer to
> call them bugs)

Bugs are only one type of stupid human error. Admins with fully enabled
capabilities can cause massive destruction, even without evil intent.

> are inevitable in every code. You can't avoid them. The only thing you
> can do is limit the scope of damage that can be done if they're exploited.
> So bugs are very much the concern of the security system.

Some bugs, including all buffer overflows, are severe. The distinction
between pP and pE makes no difference for these bugs. Other bugs are
much less severe, and can only be exploited by tricking the process into
doing something that it shouldn't do.

>> It is true that you could just enable
>> all the rights you have and "rm -rf /" at will, but that requires full
>> control over the executable _and_ evil intent.
>
> Please read your passage at the bottom of the mail and evaluate on how
> much control over the executable would such a shell have? And if you
> had something like that happen on your system (and it wasn't authorized),
> what intent might that have?

[it was a buffer overflow]

>> Reduced bits in the effective set gives you:
>>
>> 1. some protection from stupid mistakes
>> 2. some protection from trusted executables with bugs
>
> Would you mind showing me how the effective set helped the security of the
> system if something like what you described below happened? (If you would
> like, I can give you a hint on what the first thing such a shell might do
> would be)

No, it is obvious that no additional protection is provided when the
attacker is able to get such absolute control over the process.

Consider a race condition instead. The process has the ability to
delete any file in pP, but did not put it in pE. The process tries
to delete a file while the attacker changes symbolic links.

The exploit would be stopped, because the attacker is unable to
raise capabilities in the privileged process.

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