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

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


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.

Keep shared folder vs noexec in mind too.

Tor Browser is in user home folder. (Details of this mess: https://www.whonix.org/wiki/Tor_Browser/Advanced_Users#Tor_Browser_Update:_Technical_Details) 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.


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

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 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.




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

Qubes has:



# Default initial size is '50%' (of physical RAM at system startup)
# Because of memory ballooning this happen to be very low number

Dunno if that works though.

mount | grep -i strictatime

No output.

1 Like

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: https://www.whonix.org/wiki/Malware), 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

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

Edit by Patrick:

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

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?

Quote https://www.freedesktop.org/software/systemd/man/systemd.mount.html


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 " %% ".


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

1 Like

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


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?

https://github.com/Whonix/security-misc/blob/master/lib/systemd/system/proc-hidepid.service 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


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

1 Like

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

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.



mount /home -o remount,nodev,nosuid,noexec



ticket: lock down interpreters (interpreter lock)

1 Like

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

1 Like
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]