4 ms·

Is there any drawback to opening /etc/fstab and making it read-only as suggested in the article? Why isn't this the default? (in other words: what does benefit

Is there any drawback to opening /etc/fstab and making it read-only as suggested in the article? Why isn't this the default? (in other words: what does benefit from ro not being the default besides people trying to hack into the box?)

reidrac 14y ago
It really doesn't matter, its permissions are 0664 and the uid/guid are 0/0 (root.root). It may protect you in case of a mistake, your editor should warn you that the file is read-only. I don't like the post, it's too complicated for small benefits (if any). Besides there's no "generic secure setup", I think it depends on what you want to do with that server (ie. making /dev/shm read only may have impact on some software). EDIT: I think I misunderstood your comment.
- deluxaran 14y ago
  I tend to agree with you about the "generic secure setup". The problem with making read only some parts of the file system, as other persons said too, is when a legit application will want to access those locations, a better solution is to remove execute rights on the desired locations.
agwa 14y ago
> what does benefit from ro not being the default /dev/shm is used by the POSIX shared memory implementation (i.e. shm_open) and can also be used as a general temporary directory (like /tmp) that's memory-backed. Legitimate applications use it and legitimate applications will break if you follow this advice. There's nothing inherently unsafe with /dev/shm - it's very similar to /tmp. It's possible some applications use POSIX shared memory unsafely, but that's a problem with those applications. Doing something drastic like making /dev/shm read-only, if it even serves a legitimate security purpose, should only be done as a last resort.
- WestCoastJustin 14y ago
  Read-only would be bad! You want no-execute on /tmp/, /var/tmp, /dev/shm and they should be their own partitions on a secure system. The reasoning is that if someone does break into your system via apache/php or something else, they will almost always want to get a binary to elevate their access level (i.e. root the machine). They download a binary to a temporary location and execute the code (This can happen in apache/php directories too but most of the time these are locked down). Setting these to no-execute does not allow the attacker to execute code on your system. This is just a minor slowdown but does greatly help to prevent automated attacks. The goal is to slow people down to improve your chances of being alerted. I think this is fiarly standard and is listed as a best practice via the NSA RHEL hardening guide [1]. [1] www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
  - fduran 14y ago
    "Setting these to no-execute does not allow the attacker to execute code on your system". It depends, with /lib/ld-linux.so.2 /tmp/script or bash /tmp/script.sh it may be possible to execute code on a noexec /tmp . As you said, setting noexec still helps preventing automated attacks.

reidrac 14y ago

It really doesn't matter, its permissions are 0664 and the uid/guid are 0/0 (root.root). It may protect you in case of a mistake, your editor should warn you that the file is read-only. I don't like the post, it's too complicated for small benefits (if any). Besides there's no "generic secure setup", I think it depends on what you want to do with that server (ie. making /dev/shm read only may have impact on some software). EDIT: I think I misunderstood your comment.

deluxaran 14y ago
I tend to agree with you about the "generic secure setup". The problem with making read only some parts of the file system, as other persons said too, is when a legit application will want to access those locations, a better solution is to remove execute rights on the desired locations.

agwa 14y ago

> what does benefit from ro not being the default /dev/shm is used by the POSIX shared memory implementation (i.e. shm_open) and can also be used as a general temporary directory (like /tmp) that's memory-backed. Legitimate applications use it and legitimate applications will break if you follow this advice. There's nothing inherently unsafe with /dev/shm - it's very similar to /tmp. It's possible some applications use POSIX shared memory unsafely, but that's a problem with those applications. Doing something drastic like making /dev/shm read-only, if it even serves a legitimate security purpose, should only be done as a last resort.

WestCoastJustin 14y ago
Read-only would be bad! You want no-execute on /tmp/, /var/tmp, /dev/shm and they should be their own partitions on a secure system. The reasoning is that if someone does break into your system via apache/php or something else, they will almost always want to get a binary to elevate their access level (i.e. root the machine). They download a binary to a temporary location and execute the code (This can happen in apache/php directories too but most of the time these are locked down). Setting these to no-execute does not allow the attacker to execute code on your system. This is just a minor slowdown but does greatly help to prevent automated attacks. The goal is to slow people down to improve your chances of being alerted. I think this is fiarly standard and is listed as a best practice via the NSA RHEL hardening guide [1]. [1] www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
- fduran 14y ago
  "Setting these to no-execute does not allow the attacker to execute code on your system". It depends, with /lib/ld-linux.so.2 /tmp/script or bash /tmp/script.sh it may be possible to execute code on a noexec /tmp . As you said, setting noexec still helps preventing automated attacks.