LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Protective partitioning: is it effective? (https://www.linuxquestions.org/questions/linux-security-4/protective-partitioning-is-it-effective-4175575472/)

Sen-Dion 03-20-2016 11:50 PM

Protective partitioning: is it effective?
 
I am running Linux workstation for more than 10 years. Up until now, I didn't pay attention on the mount options of the partitions that the filesystem hierarchy is composed of.

Recently, I came across recommendations published by the Centre for Internet Security. I realized that I don't understand the rationale for their recommendations. I tried in vain to plough through this aspect by reading protective partitioning.

My objective is to come up with the permission scheme that:
  • first and foremost, minimizes harm caused by the inadvertent actions conducted by a user or an administrator
  • secondly, makes the life of malware/virus somewhat more miserable
My assumptions are:
  • the administrator can effortlessly carve up as many logical volumes as needed (preferable to stay below two dozens).
  • the administrator doesn't need to worry about physical size of each individual volume (similar to LVM)
  • the administrator can easily remount volume to change temporarily its mount permissions
I am going to write down below what I have learnt. It would be nice to receive a review feedback.

1. nodev mount option
Recommendation:
Quote:

nodev shall not be set on the /dev mounting point. Ideally, it should be set everywhere else. At least, set it on /tmp, /home.
What is the use case for this recommendation?

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?


2. noexec mount option
Recommendation:
Quote:

noexec shall not be set on /opt, /root, /usr, /srv mounting points. Ideally, it should be set everywhere else. At least, set it on /tmp, /dev/shm.
What is the use case for this recommendation?

It seams that the user process will not be able to create executable files in /tmp, /dev/shm? 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" does noexec provide?

3. nosuid mount option
Recommendation:
Quote:

nosuid shall not be set on /opt, /root, /usr mounting points. Ideally, it should be set everywhere else. At least, set it on /tmp, /dev/shm.
What is the use case for this recommendation?

It seams that the user process will not be able to elevate its privileges by invoking executable files from /tmp, /dev/shm? 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" does nosuid provide?

I forgot to mention that the workstation is connected to the LAN, so that other LAN users may log in using ssh service.

Emerson 03-22-2016 09:07 AM

You are assuming attacker has access to root filesystem. In most cases the attack is remote and IF the attacker is successful his access is limited. For instance, breaking in thru FTP he will find himself in ftproot (never allow FTP access to '/'). When ftproot is on a partition which is mounted noexec he will not be able to escalate his attack.

Sen-Dion 03-22-2016 12:24 PM

Thank you for shedding some light on this subject. I fully understand the use case when an attacker breaks through FTP. However, I remain somewhat in the dark in respect to the following two situations:
a) All incoming network services on this workstation are closed.
b) All incoming network services on this workstation are closed, except SSH.
Would you be so kind, and give 1-2 examples for both a) and b).

I forgot to mention that all network services along WAN --> LAN direction are closed on the gateway.


All times are GMT -5. The time now is 09:47 AM.