The implications of some security settings

General support questions
Post Reply
phil.e
Posts: 97
Joined: 2018/02/13 20:28:14

The implications of some security settings

Post by phil.e » 2021/04/06 19:11:09

I was wondering about the possible implications of some security settings that are required to be implemented in our environment.

For one, the /tmp folder is supposed to be on its own separate partition and has to be mounted with the options nosuid, noexec, and nodev. I've already seen some ways that causes issues - a few different applications that need to be installed from the /tmp folder won't install because they can't execute from /tmp - you need to disable those options, remount /tmp and then they install correctly.

Another setting we're supposed to add to /etc/fstab is this one:

/tmp /var/tmp none rw,noexec,nosuid,nodev,bind 0 0

This came up because I noticed while doing a yum update an error that popped up, something about failure to rebuild something in /var/tmp/rpm-tmp Line 50. And when I grepped for /var/tmp in /var/log/messages, there were a huge number of messages about "journal: Failed to enumerate children of /var/tmp/systemd-private<bunch of random strings>. Error opening directory, permission denied"

Sometimes these more obscure security settings cause weird problems or instabilities that are very difficult to troubleshoot because you're not dealing with a standard CentOS (or whatever OS you're using) anymore.

What are the potential problems that these noexec,nosuid,and nodev options might have on /tmp and /var/tmp?

User avatar
KernelOops
Posts: 428
Joined: 2013/12/18 15:04:03
Location: xfs file system

Re: The implications of some security settings

Post by KernelOops » 2021/04/06 21:00:49

A separate /tmp partition mounted with noexec,nosuid,nodev is a very important security feature and it is highly recommended for production systems.

This prevents all kinds of attacks after compromise, the /tmp is readable and writeable but pretty useless for anything else. A malware will usually download a remote executable, save it under /tmp and try to run it, which is something that won't work with noexec.

A separate /tmp partition has another important bonus, it protects the system from filling up the root partition and causing a system collapse. Thus, you can create really really small /tmp partitions (in MiB) and not really care what happens in there.

These days, the /tmp partition is not a real disk partition, but a tmpfs storage paradigm. It lives in memory and its size can be adjusted in real time.
--
R.I.P. CentOS :cry:
--

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: The implications of some security settings

Post by TrevorH » 2021/04/06 21:37:34

And if your apps are not working after setting /tmp noexec,nosuid then those apps are broken and need to be fixed.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

phil.e
Posts: 97
Joined: 2018/02/13 20:28:14

Re: The implications of some security settings

Post by phil.e » 2021/04/06 21:52:40

The apps work fine after installation - it's just the installation itself that craps out. I reset it back after the installation is done.

What about the error in /var/log/messages "journal: Failed to enumerate children of /var/tmp/systemd-private<bunch of random strings>. Error opening directory, permission denied"

Is that just noise and can it be ignored?

User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: The implications of some security settings

Post by TrevorH » 2021/04/06 22:02:41

I don't think /tmp and /var/tmp can be the same filesystem. For example on my test 8 VM I have two systemd-private dirs for chronyd, one in each of /var/tmp and /tmp and they are differently named with differnet random strings in the name. I suspect it's that that those messages are complaining about.

Also, /tmp is meant to be volatile and its contents lost on rebot. /var/tmp is not and its contents are meant to be preserved over a reboot.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Post Reply