Appology ======== I apologize for the broken text formatting. I am resending the same post with the fixed formatting. Introduction ============ I am running Linux workstation for about a decade. Recently, I paid attention that certain parts of the filesystem hierarchy could be carved up to facilitate the restrictive partitioning. For instance (excerpt from http://www.oclug.on.ca/archives/linux/2005-August/000276.html): / rw /usr ro,nodev /usr/local rw,nosuid,nodev /home rw,nosuid,nodev /ext1-1 rw,noexec,nosuid,nodev /var/exec rw,nosuid,nodev /var rw,noexec,nosuid,nodev Access Control List =================== I am aware that the file system maintains the Access Control List (ACL) for every object like file, directory, or device. In short, the aforesaid mount options override the ACL entries. For instance: $ getfacl -t some_file # file: some_file USER some_user rwx GROUP some_group r-x other r-- After the partition (on which 'some_file' resides) is mounted with 'ro' option, the 'ro' option overrides the 'w' permission, which renders 'some_file' as being a non-writable file for any user. Questions ========= One may continue to carve up partitions to the point where restrictive mount options such as ro, noexec, nosuid, nodev are fine tuned. My big questions are: 1. Why override ACL entries? Aren't ACL entries good enough to fine tune the restrictions? 2. How far to go with the restrictive partitioning? I feel that at some point, carving up more partitions just increases complexity of the filesystem hierarchy without providing any additional benefits. Goals ===== A. First and foremost, minimize harm caused by the inadvertent actions conducted by a user or an administrator. B. Secondly, if the restrictive partitioning improves the system resilience against malware/viruses, then it is a good bonus. Assumptions =========== Please, address the aforesaid questions under the following assumptions: a) All incoming network services on this workstation are closed. b) the administrator can effortlessly carve up as many logical volumes as needed (preferable to stay below two dozens). c) the administrator doesn't need to worry about physical size of each individual volume (similar to LVM) d) the administrator can easily remount volume to change temporarily its mount restrictions. For instance, partition mounted 'ro', can be easily remounted 'rw' for some maintenance action, and then remounted with 'ro'. Concerns ======== nodev ----- As a user, I tried to create a character device. Linux didn't allow me to run 'mknod'. Given that user process cannot create device anyway, what "piece of mind" nodev does provide? noexec ------ It seams that the user process will not be able to create executable files in /tmp, /dev/shm, once these are mounted with 'noexec' option. But what about other places? For instance, /home/$USER, or /run/user/$(id -u) ? Given that there are alternative places where user process may create executable files, what "piece of mind" noexec does provide? nosuid ------ It seams that the user process will not be able to elevate its privileges by invoking executable files from /tmp, /dev/shm, once these are mounted with 'nosuid' option. But what about other places? Given that there are alternative places where user process may elevate its privileges by invoking executable files, what "piece of mind" nosuid does provide?