mjhjmtu

long story short if you can execute code on a box it is usually straightforward to get root

(quote source)

The immediate implication of this quote (if it's accurate) is that if you're running a multi-user system and don't try your darndest to prevent all users from creating files with x permission set the system is as good as compromised. The corollary is that operating a multi-user system, such as ones typically found in universities, that by design allow all students to do exercises in C, C++, assembly etc, is pointless, since any student can straightforwardly root this system.

Since running computer systems intended to be used by more people than their owners is not considered pointless and privilege limiting facilities (users' rights management, sandboxing, etc etc) are not considered useless, I somehow doubt this kinds of comments. But what can I know?

Is it true that most Linux systems are straightforwardly rootable by anyone who can execute code on them?

No, this is not correct. While one may argue about the relative difficulty of finding and exploiting 0day vulnerabilities on Linux when you have local access, the security architecture itself of a modern Linux system (with an MMU) is designed to isolate different users and prevent privilege escalation. A non-root user cannot gain root without proper authorization without exploiting an extant vulnerability, and such privilege escalation vulnerabilities are very quickly patched as soon as they are discovered.

It is possible, however, to abuse the human factor and gain root by exploiting common misconceptions ubiquitous to the sysadmin profession. For example, if you use sudo to elevate privileges to root from an untrusted user, then that untrusted user can log keystrokes made and obtain the root password. Since many sysadmins routinely abuse sudo in this way, you could say that it is straightforward to root a Linux box once you have unprivileged local code execution. This is, however, dependent on the sysadmin not understanding the security architecture of their system. A few other examples:

• Tricking a sysadmin into running ldd on a malicious static executable as root.




• Dropping down to a lesser user from root, allowing a TTY pushback attack.