Donate

Categories

Advert

XHTML

Valid XHTML 1.0 Transitional

Defense in Depth and Sudo

My blog post about logging in as root and whether sudo provides any benefit [1] got some interest on Redit. In the Reddit comments on my post [2] there are a lot of strange things. One interesting comment was to suggest that logging in as non-root provided “defense in depth”.

The NSA is credited with inventing the term “Defense in Depth” as applied to the computer industry, they have a PDF that gives an overview of the concept [3]. It seems that Defense in Depth is all about having multiple different layers of security, firewalls, IDS/IPS, passwords, PKI, etc. Entering the same password twice (once to login and once to run sudo – which seems to be a fairly typical configuration of sudo) hardly seems to count.

Can using sudo provide Defense in Depth benefits?

With a typical configuration the use of sudo provides no real protection. The user either enters their own password or the root password to gain full root access, in either case the attacker can exploit their session and get the password. A session exploit can be easily arranged by creating a shell function or alias that makes sudo run something else (such as using netcat to send the password out over the network).

One way of making this sort of attack more difficult is to make root own the user home directory, files such as ~/.login that are used by the user shell, the ~/.ssh directory and the ~/.ssh/authorized_keys file. This way a hostile party can’t change the configuration, so a successful attack has to involve a long running process that uses ptrace to intercept the shell and divert an attempt to run sudo.

If the non-root user is prevented from using ptrace then things start to become a little more difficult for the attacker. In some quick tests I was able to capture about half the data through messing with /proc/X/fd/0 and /proc/X/fd/1 for a target process, but it seems that it would be difficult to get an entire password that way. To disable ptrace you could compile a kernel without ptrace support, use a SE Linux policy that prevents prevent ptrace access for the sessions in question, or make the user’s shell SETGID.

If the root account and the account used for su or sudo use different authentication methods, where the options include ssh authorized keys, password, and security token (maybe both password and token for the root account) then it does seem that it would provide some Defense in Depth benefits.

sudo can be used to only permit executing certain commands. While this is a real security benefit it doesn’t allow full sysadmin work, merely delegating some portions of operations to people who don’t have full sysadmin rights. As someone needs to have full access to fix any problem that might occur on the machine someone needs to have access to run any command as root. So while sudo is great for providing limited administrative access to certain junior people, it’s not going to stop an attack on a member of the sysadmin team.

Conclusion

In a typical sudo configuration the non-root account is configured in a default Unix manner (with the user having ownership of their home directory). The user who logs in to that account controls it’s environment through .login and other scripts, so sudo doesn’t gain anything.

In a typical configuration ptrace is enabled so even if the critical environment files can’t be modified by a hostile party they can get the same result through ptrace. Admittedly using a SETGID shell is not going to be difficult to implement after you have changed the ownership of the home directory.

If you have a configuration where ptrace is not available and the non-root user can’t modify their own profile files then it starts to become difficult for an attacker. If root authentication requires using a security token such that every login uses a different code and the code expires rapidly then it becomes even more difficult for an attacker.

But for all configurations that are close to the default for every OS that I’ve ever used none of these conditions hold. Also none of those conditions held for any of the systems I’ve been employed to use which were configured to require su or sudo for root access.

As it seems that most sudo configurations don’t provide any extra security, and that auditing the actions of the sysadmin can be better done in other ways (such as the Bash 4.1 syslog feature) [4] it seems that for the vast majority of systems sudo doesn’t provide a benefit.

The fact that sudo could provide a benefit if configured in a way that is quite different to all the defaults and the ways that it is typically used is worth noting. I’m not going to argue with anyone who wants to configure their systems in such a manner and who believes that they need to do so. But anyone who thinks that sudo is the only way to go because the Ubuntu default configuration does it really needs to investigate the issues. Remember that blind faith in the security choices of other people can be a security problem.

6 comments to Defense in Depth and Sudo

  • zomglol

    Defense in depth means adding layers of security to slow an attacker down.

    Using root removes depth. You can use other tools such as denyhosts to block attacks but one should be doing that anyway.

    1: ssh as root (yes)-> password cracker -> pwn

    2: ssh as root (no)-> user dictionary -> find valid user (yes) -> password cracker -> pwn

    Plus you have a one liner at the end of your article about not using sudo in it’s default configuration, well I would argue that if you are using sudo in its default configuration you shouldn’t be responsible for security of systems anyway.

  • etbe

    Depth in terms of “Defense in Depth” means things such as denyhosts, not merely entering a second password.

    http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf

    There has been research on this matter (see the above URL). In summary the entropy in the user-name does do some good if you have a large number of accounts (such as an Internet banking service for a major bank) such that a multiple attempt lock-out doesn’t work. But if you have a small number of accounts (less than 10,000 or so) and any sort of limit on the rate of attempts per account then the overall scanning rate will not lead to any significant risk of attack.

    The mechanisms for securing Internet banking are quite different from those for securing servers for sysadmin login.

    Besides, there is no reason why the account for UID==0 needs to be named “root”. You can easily configure a system with account “root” locked and have another name for the account that is really used for UID==0 access.

  • robw

    In a web hosting environment the most common type of attack is automated, done on a massive scale across thousands of hosts, in an attempt to find some weak and easy targets to build up a botnet. Against this the login-twice method does actually provide some protection. The attackers would be able to get around the protection if they used intelligence and effort, but 99% of the attackers don’t care to try as they’re getting plenty of success with even less protected servers.

    As an anecdote I’ve often seen servers which have technically been compromised, in that a user account (such as ‘apache’) has been breached, but the attacker has only tried to run some pre-written scripts and shown no imagination in finding weaknesses specific to the server itself. Blocking most outbound ports at the firewall is often enough, so that they can’t run an IRC server, for example.

    You quite rightly discuss how to make a server the most secure, much as how someone could talk about making their house more burglar-proof. The truth is that most attackers, both physical and virtual, are lazy enough that even weak protection is good enough for a majority of cases.

    So yes, I fully agree with what you say – sudo isn’t much of a protection at all against someone who knows Linux well – but it is good enough to limit damage from a non-determined hacker.

  • etbe

    robw: Any half competent script author would at least try using sudo with the same password any time that they cracked a user account, so the same password twice isn’t going to help.

    The script kiddies have collections of kernel exploits etc, so it would be quite possible for them to have an exploit that replaces sudo with a shell function that exports the password elsewhere.

  • robw

    They’ve been able to do that for more than a decade and yet still don’t in the majority of attacks to lower profile websites, so even a pathetically weak defense is ‘good enough’ for a lot of cases. If you have the time then definitely put something better in place, I wouldn’t argue against that, but don’t discount the cheap methods as worthless.

    By way of metaphor, most people’s houses aren’t highly secure against burglary and so most burglars are skilled at identifying weakly protected houses. Is a security light good protection? No, but it’ll put a lot of them off, and that’s what we’re aiming for here. We can inconvenience the lazy attackers enough for them to go elsewhere even with trivial and easily-breakable measures like sudo.

    Interesting post though, it’s good to think about these things.