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

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Wed, 21 Apr 1999 14:56:03 +0200

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.
>>
>> Ok, I agree completely with this; I don't see any good use for fE, it
>> really doesn't enhance security; if someone can explain to me why it
>> might, I'd be interested (Ted?)
>
>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) 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.

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

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

>>> Furthermore, the POSIX privileges contain the third set of capabilities,
>>> the inheritable set, which is also a design failure as it makes the
>>> design to fail to contain the damage in case of a buggy privileged
>>> binary. Once a privileged binary is broken into (for example at
>>> runtime by means of a stack overrun), it can be made to spawn an
>>> arbitrary child (such as a shell for example) that will inherit
>>> the authority of a buggy parent, thus enabling an attacker to gain
>>> unauthorized access in a useful form (a shell for example). [...]
>
>This does not make a difference, since the stack overrun can _be_ a
>shell after it loads some more code. There is no need to exec().
>Using threads, the exploit code could even emulate multiple processes.

Andrej

--
Andrej Presern, andrejp@luz.fe.uni-lj.si


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