(re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

Development
,
1

Could we gain security by mounting home with noexec (and nosuid [among other useful mount options])?

How does noexec help if one can use

  • bash ./script
  • sh ./script
  • python ./script

etc.?

EDIT: bash ./script etc. does not require ./script being executable. It will work on any file even when setting chmod -x ./script beforehand.

ticket: lock down interpreters (interpreter lock)

noexec might make most sense when combined with all the other stuff form Related below tin this post?

lynis even recommended to prevent access to compilers such as gcc.

EDIT:
Keep shared folder vs noexec in mind too.

Tor Browser is in user home folder. (Details of this mess: Tor Browser Advanced Topics) And needs some files being executable.

So it may not be possible to mount home with noexec for all VMs. But letā€™s overlook Tor Browser for a moment. Maybe a solution could be found. (Such as a wrapper.) Edit: created Tor Browser vs NOEXEC - Where should the Tor Browser folder be placed? for it.

Either way this could at least be an easy opt-in with most things shipped by default but not enabled by default if not a good idea.

Related:

I also had in mind various boot modes:

  • persistent + root
  • persistent + noroot
  • live + root
  • live + noroot

Not all might make sense.

Or think of noroot has ā€œhardeningā€ where we can do stuff like noexec, nosuid, no root/sudo possible at all.

But various boot modes is best discussed in a separate thread. Please quote me on this in a different thread. Just wanted to briefly mention the idea here so that something that isnā€™t great as a default for everyone all the time must not necessarily block alternative configurations / boot options. Created:

1 Like
2

noexec might prevent those from being run but Iā€™m not sure.

That would give a very minimal security gain and is mostly useless. An attacker could easily just pre-compile their stuff or bring their own compilers.

It could be moved elsewhere. Shouldnā€™t be too hard. Edit by Patrick: See Tor Browser vs NOEXEC - Where should the Tor Browser folder be placed?

Thereā€™s a RHEL hardening presentation that gives a good idea of what mount options to use and where to use them.

The mount options are at page 15.

Noexec on everything possible

Nodev everywhere except / and chroot partitions

Nosetuid everywhere except /

There is also a section on the CentOS Protection guide and Arch Linux Security guide about this.

https://wiki.centos.org/HowTos/OS_Protection#head-73cf15dd0e0cdf531bfc263e6694c79664962622

https://wiki.archlinux.org/index.php/Security#Mount_options

2 Likes
3

On subject of drop-in files for systemd unit files.

Qubes has:

/lib/systemd/system/tmp.mount.d/30_qubes.conf

qubes-core-agent-linux/vm-systemd/tmp.mount.d/30_qubes.conf at master Ā· adrelanos/qubes-core-agent-linux Ā· GitHub

[Mount]
# Default initial size is '50%' (of physical RAM at system startup)
# Because of memory ballooning this happen to be very low number
Options=mode=1777,strictatime,size=1G

Dunno if that works though.

mount | grep -i strictatime

No output.

1 Like
4

madaidan via Whonix Forum:

noexec might prevent those from being run but Iā€™m not sure.

No, does not. bash /path/to/script (or any script interpreter) works for files without executable permission set.

That would give a very minimal security gain and is mostly useless. An attacker could easily just pre-compile their stuff or bring their own compilers.

Is it worth to fence off off-the-shelf malware (as defined here: Malware, Computer Viruses, Firmware Trojans and Antivirus Scanners), i.e. non-targeted / non-tailored malware? I think yes. Many users would value that a lot. Moves up the bar.

It could be moved elsewhere. Shouldnā€™t be too hard.

Any idea for that? If yes, could you please create a new thread for that?

1 Like
5

I donā€™t think most off-the-shelf malware would do that though. I think most would be pre-compiled.

Edit by Patrick:

6

I think we should start off with mounting /tmp with noexec, nosuid and nodev. /tmp is a common place for malicious executables.

We can do it similar to the hidepid implementation although a proper fstab implementation would be much better but fstab.d isnā€™t a thing yet.

1 Like
7

Implementation wise there might be something even better.

Could you try drop-in folder /lib/systemd/system/tmp.mount.d please?

As per (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security? - #3 by Patrick

Quote systemd.mount

Options=

Mount options to use when mounting. This takes a comma-separated list of options. This setting is optional. Note that the usual specifier expansion is applied to this setting, literal percent characters should hence be written as " %% ".

2 Likes
8

That doesnā€™t work as there is no /lib/systemd/system/tmp.mount file.

1 Like
9

Could just have a single systemd unit that runs a mount (or remount) on all folders we want to modify?

Or better one systemd unit file per one folder where we want to change mount options?

Does anything speak against mount --bind?

sudo mount -o noexec,nosuid,nodev --bind /tmp /tmp

Or.

sudo mount -o remount,noexec,nosuid,nodev --bind /tmp /tmp

Then do that for all folders we care about. Probably leave out noexec for /home.

Should that script be configurable? Configuration would actually be easy to add. Then someone could opt-in to choose noexec for /home. But could be wasted effort since Iā€™ve not seen convincing arguments for /home with noexec.

The only problem so far I saw with the script that itā€™s not easily made idempotent. If we didnā€™t use mount --bind previously, we have to drop mount option remount. But if the script (or some other script or custom fstab or user or whatever) has run before, then we have to use remount. That adds slight to ugliness the code. Better would be ā€œignore remount if not yet mounted then just mount itā€. Does that exist?

security-misc/proc-hidepid.service at master Ā· Kicksecure/security-misc Ā· GitHub currently has an issue: It races. Itā€™s execution time during the boot process is not fixed/ā€œguaranteedā€ (ā€œreasonably guaranteedā€).

It uses Requires=local-fs.target and After=local-fs.target but it lacks Before=.

Ideally it would run as exactly the next systemd unit after systemd did that mount before any other systemd units do anything. (Except these are the same security level.)

This is important since hideproc=2 is being used to prevent malicious processes from gathering information. Ideally, weā€™d never mount without improved mount options. Initial mount during boot with improved mount options already. This isnā€™t possible due to technical reasons.

But by what time a malicious process starts? We should make sure it most likely starts after improved mount options were applied.

Perhaps add

Before=sysinit.target

? Dunno if that would require using DefaultDependencies=no too.

1 Like
10
2 Likes
11

There is --bind and --rbind. Looks like what we want is --rbind?

Need to make sure that the original mount is no longer accessible. For example if we mount /tmp on top of /tmp with more secure mount options, then the original /tmp must no longer be accessible. Is that the case or some trick how a non-root user could still access the original /tmp?

1 Like
12

Yes, that sounds like a good idea.

Not that I know of.

It would probably be unneeded complexity. I doubt most users would want to change the mount options.

I donā€™t think thereā€™s any way to do that with just mount. We could grep the output of mount and if it isnā€™t there, leave out remount.

I donā€™t think there would be a big difference.

It should be the case. I donā€™t know of any way to access the original /tmp.

2 Likes
13

https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md

mount /home -o remount,nodev,nosuid,noexec
2 Likes
14

https://www.cyberciti.biz/faq/howto-mount-tmp-as-separate-filesystem-with-noexec-nosuid-nodev/

https://secscan.acron.pl/centos7/1/1/17

2 Likes
15
2 Likes
16
2 Likes
17

ticket: lock down interpreters (interpreter lock)

2 Likes
18
1 Like
19

Fixes (noexec) and enhancements in git master and developers repository.

1 Like
20
1 Like