commit a4a93deeb65fef89b09a08e058984affccb0da0c
parent ab836e7dab3dfb3811eae61d884323531f48f223
Author: pyratebeard <root@pyratebeard.net>
Date: Fri, 26 Aug 2022 17:07:58 +0100
arcane_lock
Diffstat:
1 file changed, 68 insertions(+), 0 deletions(-)
diff --git a/entry/arcane_lock.md b/entry/arcane_lock.md
@@ -0,0 +1,68 @@
+It is common for system administrators to be thought of as strict gatekeepers, not allowing access to anybody.
+
+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.
+
+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.
+
+## ed, edd, and edit
+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`.
+
+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
+```
+bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf
+```
+
+The user can then edit the file in one of two ways
+```
+sudo -e /etc/httpd/conf/httpd.conf
+sudoedit /etc/httpd/conf/httpd.conf
+```
+
+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.
+
+Wildcards can also be used to specify whole directories or multiple files
+```
+bob ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf, sudoedit /etc/httpd/conf.d/*.conf
+```
+
+## (e)u:4(ia)
+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
+```
+sudo setfacl -m u:bob:r /var/log/messages
+```
+
+Group permissions can also be set with
+```
+sudo setfacl -m g:bob:r /var/log/messages
+```
+
+To view a file's ACLs incant
+```
+sudo getfacl /var/log/messages
+```
+
+The output will look something like this
+```
+getfacl: Removing leading '/' from absolute path names
+# file: var/log/messages
+# owner: root
+# group: root
+user::rw-
+user:bob:r--
+group::---
+mask::r--
+other::---k
+```
+
+Removing a user's access once they no longer need it is done with the `-x` option
+```
+setfacl -x u:bob /var/log/messages
+```
+
+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.
+
+#### rotate me right round
+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.
+
+## go forth and sudo
+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.
