Is there a way to keep sudoers from editing stuff in /etc/ssh/sshd_config?

Question

I have root login disabled in SSH and I want to be able to eliminate the possibility of a sudo user editing the /etc/ssh/sshd_config file and enabling root ssh login. Is this possible?

Answer 1

Ultimately, blacklists don't work: it would be a vain endeavour to try to find all ways by which a root-equivalent user could alter the contents of /etc/ssh/sshd_config and try to fix them all. For instance, a lot of commands can output some data in a file whose name is provided as parameter -- that could be used to alter /etc/ssh/sshd_config.

Instead, use whitelists: explicitly allow sudoers to run an explicit, small sets of commands (e.g. a command to trigger a reboot, if that is relevant to your situation), and all others must be forbidden.

Alternatively, use SELinux to constrain sudoers into a not-exactly-root role and get /etc/ssh/sshd_config out of their reach. But this may involve some considerable configuration work (SELinux seems to be up to the task, but I have not tried it, so I do not guarantee success here). Also, be aware that the power of nuisance of a rogue root user tends to be pervasive: there are many many ways by which such a user can harm your security. It seems better to just not trust evil people with sudo powers. Or maybe some more comprehensive isolation layer would be warranted: instead of having several users in a single machine, with some semi-administrative powers, give a virtual machine to each user, that he may play with at will without impacting the other users. Depending on your context, this may or may not be applicable.

Answer 2

The closest you are going to get to making that impossible is to use an extremely restricted set of what is possible through sudo. You will have to forbid access to vi, editors, shells and su. You're better off trying to determine what commands are necessary and hoping none of them have the ability to edit files or directories or execute commands.

Ultimately if you are giving someone privileges on your system, you are inviting risk.

There are some other alternatives you can consider:

Monitor the SSH logs for root logins with password auth. That's your leading indicator that your file has been changed.

Monitor that file for changes with a frequently running cron. If someone modifies that file and doesn't notice the monitor, you'll catch it.

Answer 3

Yes, with AppArmor it might be possible:

I have tried arround somewhat with using MAC (mandatory access control) and the AppArmor LSM (linux security module) and I found, that you might have a change using AppArmor to make /etc/ssh/sshd_config impossible to be written to using sudo.

This AppArmor profile would limit what the user can do after having gained "root power" via sudo

/usr/bin/sudo {
  capability setgid,
  capability setuid,
  / rw,
  /** rwmix,
  deny /etc/ssh/sshd_config w,
  deny /usr/sbin/aa* rw,
  deny /sbin/app* rw,
  deny /usr/bin/sudo rw,
  deny /etc/apparmor.d/profile.usr.bin.sudo rw,
  deny /sys/kernel/security/apparmor/ rw,
  deny /sys/kernel/security/apparmor/** rw,
}

To be safe, first lookup if there is already an preexisting AppArmor profile for /usr/bin/sudo

$ aa-status | grep sudo

In case there is none the output is empty! If not empty you should best talk to those guys who have setup the profile and not go on here.

If - as expected - there is not yet a profil you ca create one with this command:

root@computer:/root/# echo "/usr/bin/sudo {
>   capability setgid,
>   capability setuid,
>   / rw,
>   /** rwmix,
>   deny /etc/ssh/sshd_config w,
>   deny /usr/sbin/aa* rw,
>   deny /sbin/app* rw,
>   deny /usr/bin/sudo rw,
>   deny /etc/apparmor.d/profile.usr.bin.sudo rw,
>   deny /sys/kernel/security/apparmor/ rw,
>   deny /sys/kernel/security/apparmor/** rw,
> } " > /etc/apparmor.d/yourprofile.usr.bin.sudo

Then you can start/setup the new profile

root@computer:/root/# apparmor_parser -r /etc/apparmor.d/yourprofile.usr.bin.sudo
root@computer:/root/# aa-enable /etc/apparmor.d/yourprofile.usr.bin.sudo

resultingly a for a user this should be the result:

ssh_user@computer:~$ sudo bash -c "echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config"
[sudo] password for ssh_user: 
bash: /etc/ssh/sshd_config: Permission denied
ssh_user@computer:~$ sudo -i
root@computer:/root/$ echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config
-bash: /etc/ssh/sshd_config: Permission denied
root@computer:/root/$ aa-disable profile.usr.bin.sudo
Can't open perl script "/usr/sbin/aa-disable": Permission denied

Sadly I cannot give you insight how to implement this in other LSM like SELinux or grsecurity.

Anyways I would appreciate to get a feedback if the solution helped you :)

Be aware that the limitations regarding what can be done with sudo are for everybody and that means if you use sudo to get superuserpower you will suffer the same limitations (i.e. you cannot disable apparmor, nor /etc/ssh/sshd_config yourself. Only one who can is a real root via login.

Answer 4

You could write your /etc/ssh/sshd_config to a physically read only drive. In that case even if you were logged in as root itself, you could not change sshd_config.

But then you would have to watch out for

• if the user can mount and unmount drives, then they could just unmount whatever drive you have sshd_config on
• if the user has physical access to your machine, then they could just replace the disk

Answer 5

I like Scottie's answer of chattr +i /etc/ssh/*

Perhaps then you then could use visudo -f /etc/sudoers to change to:

%sudo   ALL=(ALL:ALL) !/usr/bin/chattr, !/bin/su

This method should blacklist sudoers from running chattr and using sudo su but the easier method would just be to whitelist commands sudoers are allowed to run. All of this is one extra layer, but just like anyone with sudoer access, they can undo anything that root can.

Answer 6

If it were me, I would just set the /etc/ssh files to immutable:
chattr +i /etc/ssh/*

Are you truly worried abut the file itself changing, or could you live with just knowing that the file has been changed?
If the latter, there are various intrusion detection programs (e.g. aide) that will monitor these files and alert you if it changes.
There are also configuration management programs, such as puppet or chef that can be configured to replace the files with a known good image if it were to change.