20

I have a headless server that is logged into remotely by multiple users. None of the other users are in the sudoers file, so they cannot obtain root via sudo. However, since the permissions on su are -rwsr-xr-x there's nothing stopping them from attempting to brute force the root password.

One could argue that if a user knows the root password they can compromise the system anyway, but I don't think this is the case. OpenSSH is configured with PermitRootLogin no and PasswordAuthentication no, and none of the other users have physical access to the server. As far as I can tell, the world execute permission on /usr/bin/su is the only avenue for users attempting to gain root on my server.

What's further puzzling to me in that it doesn't even seem useful. It allows me to run su directly instead of needing to do sudo su, but this is hardly an inconvenience.

Am I overlooking something? Is the world execute permission on su just there for historic reasons? Are there any downsides to removing that permission that I haven't encountered yet?

  • 9
    "It allows me to run su directly instead of needing to do sudo su, but this is hardly an inconvenience." - What about systems without the optional sudo installed? I'd say it's a pretty big inconvenience there ;) – marcelm Aug 17 at 11:09
  • 1
    You can always restrict access for /bin/su, but remember to do the same for /usr/bin/pkexec also. – jpa Aug 17 at 16:46
  • 6
    I can't seem to understand the motivation behind this question. It sounds like you were wondering why su needs to be world executable, but what would be the point of the alternative? That is, if su were only executable by root (?), what were you thinking it could be used for? – David Z Aug 18 at 7:00
  • 1
    @DavidZ In fact, it is indeed useful for root! You can quickly switch users with it. – val Aug 18 at 8:41
  • 1
    @val Yes, that's true. The fact that root can use su is not in question here. (On rereading, I can see how my previous comment would suggest otherwise, but that's not what I meant.) I'm curious what Altay_H thought about this before they asked this question though. – David Z Aug 18 at 8:48
39

One point that is missing from ilkkachu's answer is that elevating to root is only one specific use for su. The general purpose of su is to open a new shell under another user's login account. That other user could be root (and perhaps most often is), but su can be used to assume any identity the local system can authenticate.

For example, if I'm logged in as user jim, and I want to investigate a problem that mike has reported, but which I am unable to reproduce, I might try logging in as mike, and running the command that is giving him trouble.

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

Using the -l option of su causes it to simulate a full login (per the man page).

The above requires knowledge of mike's password, however. If I have sudo access, I can log in as mike even without his password.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

In summary, the reason the permissions on the su executable are as you show, is because su is a general-purpose tool that is available to all users on the system.

  • 1
    That makes a lot of sense. Since I'm in the habit of using sudo I forgot that su can be used for more than just sudo -s. And without being a sudoer this would be the only way to switch users without altering ssh keys. For my use case this is another reason to remove the permission, but I understand now why the world execute permission is set by default. Thanks! – Altay_H Aug 16 at 20:57
  • 1
    Another point is that sudo, too, can be used to assume the identity of a user other than root. It's simply allows finer grained control over who can do what as whom, including assuming another identity without the need for that identity's password. – chepner Aug 17 at 13:57
  • Part of the confusion is that people think su stands for "super user", which it does, when no user is specified (or root is explicity specified) but it also stands for "switch user". This second use of su is therefore easily forgotten. – Monty Harder Aug 19 at 16:51
20

Historically (on non-GNU unices), it wasn't, or at least it manually checked if you were in a group called "wheel" permitted to su. The GNU version of su did not reproduce this functionality because of RMS's ideology about access control at the time:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

You can find a lot more on the matter by Googling "wheel group rms" or similar.

  • 3
    This is the only correct answer. The setting is intentional, historical, and this exactly is the reason for it. All the technical blabla is just that - blabla. You can absolutely reintroduce the "wheel" group in a modern Unix. – Tom Aug 19 at 12:11
10

However, since the permissions on su are -rwsr-xr-x there's nothing stopping them from attempting to brute force the root password.

Yes. Assuming your usual Linux system, the pam_unix.so module does delay a failed authentication attempt by ~two seconds, but I don't think there's anything to stop simultaneous attempts.

Failed attempts are logged of course:

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

Brute-forcing a password should show up prominently in the logs, if you have any kind of system for monitoring them. And if you have untrusted local users, maybe you should. Untrusted local users could also attempt to use any local-only privilege escalation exploits, and they're much more common than remote privilege escalation.

What's further puzzling to me in that it doesn't even seem useful.

Of course it's useful, it allows you to elevate yourself to root, if you know the password.

It allows me to run su directly instead of needing to do sudo su, but this is hardly an inconvenience.

sudo su is somewhat redundant. There's no need to use two programs that are meant to allow you to run programs as another user, one is quite enough. Just use sudo -i or sudo -s (or sudo /bin/bash etc.) if you want to run shell.

Am I overlooking something? Is the world execute permission on su just there for historic reasons?

See above. Well, not all systems have sudo as an alternative, I'm not sure if you consider that historic.

Are there any downsides to removing that permission that I haven't encountered yet?

Not really, no as far as I know. I think some systems have su set so that only members of a particular group ("wheel") can run it. You can do the same to sudo if you like (chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo).

Or you could just remove either or both of the programs if you don't need them. Though on Debian, su comes with the login package, so it's probably not a good idea to remove the package as a whole. (And pairing login and su together like that does seem somewhat historic.)

  • 1
    BSD systems require users to be in the wheel group to use su. There are some BSD systems (I can only speak for OpenBSD) that does not ship with sudo at all (it's a 3rd-party package). OpenBSD has doas which is a reimplementation of the basics of sudo, but it's disabled by default upon installing a fresh system. – Kusalananda Aug 16 at 20:33
  • @Kusalananda You only have to be in wheel if you want to su to root. Any account can su to any non-root account for which they have the password, regardless of their membership in the wheel group. – Jim L. Aug 16 at 20:44
  • I run 'sudo su -' to ensure that the root shell I get is a full root login, without a polluted environment from my user account. The default sudoers on RHEL includes quite a few environment variables that are executable (such as PS1). – jsbillings Aug 16 at 23:30
  • @jsbillings, hmm, ok. Does su clear the environment then? It doesn't seem to do that on Debian... – ilkkachu Aug 17 at 6:37
  • “su -“ does in every Linux I know of. Mind the dash. – jsbillings Aug 17 at 12:23
7

You already have some good answers, but there's one part of your post they don't address.

As far as I can tell, the world execute permission on /usr/bin/su is the only avenue for users attempting to gain root on my server.

That's a dangerous assumption. If you've set a good password for root, then it in most cases is far more likely that a successful privilege escalation will be due to the exploitation of a bug in the kernel or a setuid binary (you can of course also remove the setuid bit from those, but passwd is setuid, and if you want to high security you should also offer that to your users, and denying them the option of changing their password is not compatible with that).

1

su needs to be world-executable so everyone can run it. In many systems, it can be used to change to another user, by supplying their password.

If you are concerned about someone bruteforcing the root password, you could just disable it. (make the hash invalid so no given password can match it)

I don't know about the consensus, but I'd consider being able to log in as root directly a security problem in and of itself.

-2

The other answers are correct saying "su" allows you to log into accounts other than root.

One note about "sudo su" though. This actually allows you to log into the root account without knowing the root password. You do have to know the password of the account you run sudo with as well as have that account be in the sudoers file.

  • 3
    That depends entirely on whether sudoers has targetpw or rootpw set. – muru Aug 19 at 4:47
  • 1
    This has nothing to do with su being executable by all. – Kusalananda Aug 19 at 7:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.