Messages in this thread | | | From | Andrej Presern <> | Subject | Re: caps in elf, next itteration (the hack get's bigger) | Date | 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/
| |