In our last article, we covered the chmod command which allows you to manipulate file access permissions on a per-user and per-group basis.That article covered the basics, so with this one we want to get a little deeper with advanced attributes. Let's start off with 'suid' and 'sgid.'
Suid and sgid bits are useful if a user needs to run an executable that they otherwise don't have any priveleges for. Before execution, the system checks these bits and substitutes the current user's privileges to the owner`s (or owner's group) of a file. If we want to, for example, restart apache process and we`d like to delegate its execution to an unprivileged (not root or sudoer) user of our system, we'd start with the following script:
echo service httpd restart >> /home/myuser/restart-apache.sh
Make it executable:
chmod +x /home/myuser/restart-apache.sh
Change owner (if you're running these scripts as root, skip this step):
chown root:root /home/myuser/restart-apache.sh
Finally, set the suid bit and change the other permissions:
chmod 4750 /home/myuser/restart-apache.sh
In this script, 4 - SUID (Substitute user id to the owner`s for the execution process) 7 - owner have full access (read, write, execute) 5 - owner-group can read and execute, and 0 - others can do nothing.
Or you can set the SGID:
chmod 6570 /home/myuser/restart-apache.sh ls -l ./restart-apache.sh -rwsr-xr-x 1 root root 24 2016-06-02 22:03 ./restart-apache.sh
Some things to keep in mind:
1. Don`t allow the delegated user to change the file - they can replace the content and run any other command with higher privileges.
2. Some modern distributions of Linux can ignore SUID and SGID bits.
3. While the it's important to know and understand suid and sgid commands, you should probably never run them on your production servers. It`s kind of a "quick and dirty" hack, the best practice is to use sudo with options (you can grant sudo for defined user and any command specified in /etc/sudoers file) .
Sticky bits are permission bits that are left on files or directories that ensures that only the owner of the file to delete it. As a quick example:
chmod 1750 /home/shared_folder ls -l /home/shared_folder drwxr-x--T 2 root root 4096 2016-06-02 23:03 shared_folder
Here, we can see a new “T” attribute – that's the sticky bit.
Advanced file attributes with lsattr and chattr
Chattr and lsattr are two components of the e2fsilibs package. They're basically used to set other, special, attributes for file and folders. You can quickly list all their attributes using the 'man chattr' command, which will return:
append only (a), no atime updates(A), compressed (c), no copy on write (C), no dump (d), synchronous directory updates (D), extent format(e), immutable (i), data journalling (j), secure deletion (s), synchronous updates (S), no tail-merging(t), top of directory hierarchy (T), and undeletable (u) The following attributes are read-only, and may be listed by lsattr but not modified by chattr: compression error (E), huge file (h), indexed directory (I), inline data (N), compression raw access (X), and compressed dirty file (Z).
We can use 'lsattr' to view file attributes. It works almost just like 'ls -l', so we can compare the output of both:
ls -l /etc/passwd -rw-r--r-- 1 root root 1730 дек 14 16:47 /etc/passwd and lsattr /etc/passwd -------------e-- /etc/passwd
There aren't any advanced attributes set by default. Let's mix it up and set a few with chattr. If we have a file we don't want to change or delete by mistake, and don`t want to let anyone else do it either, we can set an immutable (i) attribute to it:
chattr +i /home/myuser/myVeryImportantFile.txt
Check the result with 'ls -l':
ls -l myVeryImportantFile.txt -rw-r--r-- 1 root root 0 may 30 02:53 myVeryImportantFile.txt
Nothing changed. And with 'lsattr':
lsattr myVeryImportantFile.txt ----i--------e-- myVeryImportantFile.txt
Notice the 'i' is listed now. Let's try to delete it:
rm myVeryImportantFile.txt rm: unable to delete «myVeryImportantFile.txt»: operation is not permitted
echo test >> myVeryImportantFile.txt bash: myVeryImportantFile.txt: access denied
Perfect. Exactly what we wanted. Now, let's say we want to let users add content to a file, but not to replace or delete any. We have to add an "a" (append only) attribute:
chattr +a Linux_File_Permissions_advanced.txt lsattr Linux_File_Permissions_advanced.txt -----a-------e-- Linux_File_Permissions_advanced.txt echo “Put some text to file” >> Linux_File_Permissions_advanced.txt cat Linux_File_Permissions_advanced.txt Write some awesome text!
Using this script, no one will be able to delete or change any part of that document except to write new content.
For our next trick, let's say we want to remove and completely destroy a file because it has private information in it. As you might know, the rm command does not actually remove anything – it just marks the space as free for the system, and the file system will overwrite it eventually when it needs more space. This means files can be easily restored before it's overwritten with basic software like extundelete, for example. So to prevent any restoration we can use the attribute "s", which will overwrite the file with 0s instead of just marking it as free:
chattr +s ./mysecretfile.txt lsattr ./mysecretfile.txt s----------------e- mysecretfile.txt
When you 'rm' it now, after enabling the 's' attribute the file will be deleted and unrestorable. Can be useful when old but vulnerable content needs to get deleted.
Something I'd like to mention again is that advanced attributes should only be used once you really know what you want to do with them. Personally, I don't think they should ever be used on production servers within companies and organizations, unless you have explicit awareness and permission that you're doing so. Any mistake with regards to these permissions can lead to data being compromised or lost. It's generally much safer to go with the traditional routes of backups, firewalls, antiviruses, antirootkits,encryption and server monitoring (hey, that's us!)
Until next time!