6 ms·
> 2. In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly
by tcoppi 10y ago
> 2. In almost all cases, whether or not there's a known local privesc bug, assume that code execution on your Linux systems equates to privesc; this is doubly true of machines in your prod deployment environment.
I think this goes for any mainstream OS, Linux is not particularly special here.
- qwertyuiop924 10y agoAssume it on any system. Even OpenBSD. Nobody's perfect. Not even Theo.
- umanwizard 10y ago> FreeBSD > Theo Do you mean OpenBSD ?
- qwertyuiop924 10y agoWhy yes, yes I did. Thanks for pointing that out. Edited to fix.
- ams6110 10y agoSo basically, if you wouldn't give a user sudo, they shouldn't have login access at all? Certainly works for some scenarios, but not practical for many others.
- amalcon 10y agoIt depends on why you wouldn't give a user sudo. If you're worried that they might get bored and do an immature prank, or do something ill-advised (like changing the root password, or giving sudo to someone else) and render the system insecure/inoperable/unmaintainable, you probably can give them shell access. A good example here would be giving shell access to employees or the like, if their job is aided by it. The time and effort it takes to research a privesc vuln is usually sufficient to deter them, and if it isn't, you just revoke access and fire them if they do it. If you're worried that someone might be trying to deliberately compromise your security, you can't give that person the ability to run code on your system.
- tptacek 10y agoCorrect.
- empath75 10y agothe main reason you don't give users sudo is so they don't do anything stupid, not so much to prevent them from acting maliciously.