20220826-arcane_lock.md (3552B)
1 It is common for system administrators to be thought of as strict gatekeepers, not allowing access to anybody. 2 3 In my experience nobody bats an eye when you're unable to use the Administrator account on a company laptop, but having to run `sudo` without simply switching to root on a Linux server is absurd. 4 5 The hardening and security of Linux servers is very important, yet so many people and companies fail to restrict access correctly. I have always been an advocate of enforcing the correct use of sudo, specifying commands instead of allowing full root access. Command exclusion is equally important, and in my opinion often overlooked. A good sudoers configuration will exclude users from running commands that could potentially allow them to get a root shell, this includes excluding all shells, management tools such as `chmod`, and even commands like `vim` and `tar`, which can easily be used for privilege escalation. 6 7 ## ed, edd, and edit 8 Excluding `vim` and `vi` poses an issue when users do need to edit files on the system. Thankfully the contributors to `sudo` came up with a solution, the `-e` option or `sudoedit`. 9 10 The `sudoedit` option allows a user to edit files by making a temporary copy owned by the user. To give an example, lets say we have a user that requires permission to edit the Apache config file. They can be granted access in /etc/sudoers, or my preferred method is to put a file into /etc/sudoers.d/. The line would look like this 11 ``` 12 bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf 13 ``` 14 15 The user can then edit the file in one of two ways 16 ``` 17 sudo -e /etc/httpd/conf/httpd.conf 18 sudoedit /etc/httpd/conf/httpd.conf 19 ``` 20 21 This creates a copy of the file in /var/tmp, such as `"/var/tmp/httpdXXJkszaG.conf"`, which is owned by the user. Once the changes have been made the file can be saved and exited as normal. 22 23 Wildcards can also be used to specify whole directories or multiple files 24 ``` 25 bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf, sudoedit /etc/httpd/conf.d/*.conf 26 ``` 27 28 ## (e)u:4(ia) 29 Recently I had a user who required access to read some of the system log files so they could debug an issue. As expected I didn't want to grant them sudo permission, overkill for reading some files. Instead I opted to use the file access control list tool `setfacl`. To grant a use read permissions to a file incant 30 ``` 31 sudo setfacl -m u:bob:r /var/log/messages 32 ``` 33 34 Group permissions can also be set with 35 ``` 36 sudo setfacl -m g:bob:r /var/log/messages 37 ``` 38 39 To view a file's ACLs incant 40 ``` 41 sudo getfacl /var/log/messages 42 ``` 43 44 The output will look something like this 45 ``` 46 getfacl: Removing leading '/' from absolute path names 47 # file: var/log/messages 48 # owner: root 49 # group: root 50 user::rw- 51 user:bob:r-- 52 group::--- 53 mask::r-- 54 other::---k 55 ``` 56 57 Removing a user's access once they no longer need it is done with the `-x` option 58 ``` 59 setfacl -x u:bob /var/log/messages 60 ``` 61 62 The use of ACLs means you don't need to modify the file or directories ownership but can still safely give users the permissions they require. 63 64 #### rotate me right round 65 Be careful if setting ACLs on log files as the permissions will be lost when the logs are rotated. If you require persistence add the `setfacl` line(s) to the relevant logrotate config file. 66 67 ## go forth and sudo 68 Using `sudo` should not be shied away from, but it should also not be used in an all or nothing manner. It may annoy your users but you will rest well at night knowing that you have control and no one can take that from you, something, something, gatekeeper.