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

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
1 Like

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

1 Like
1 Like


The “Filesystem layout and structuring” section has a table on which directories to use restrictive mount options on.

1 Like

Quote Kernel Hardening

1 Like
1 Like

I’ve refactored /usr/lib/security-misc/remount-secure. Should now be quite easy to add new remounts.

1 Like

This is causing many issues.

user@debian-buster-test:~$ sudo iptables --list
iptables/1.8.2 Failed to initialize nft: Protocol not supported

lsmod shows that fewer modules are load. And module auto loading is broken. This breaks Whonix firewall. Will therefore disable remounting /lib with nosuid,nodev. But no security reduction. There are no devices and no suid in /lib anyhow. And permission hardening was speed up so that parsing /lib in permission hardening is ok.

Linux Kernel Runtime Guard (LKRG) - Linux Kernel Runtime Integrity Checking and Exploit Detection can also cause iptables/1.8.2 Failed to initialize nft: Protocol not supported

1 Like

These two things must not run together.

Dec 29 04:17:12 debian-buster-test remount-secure[410]: mount -o nosuid,nodev --bind /tmp /tmp

Dec 29 04:17:12 debian-buster-test permission-hardening[413]: /usr/lib/security-misc/permission-hardening: line 255: cannot create temp file for here-document: No such file or directory
Dec 29 04:17:12 debian-buster-test permission-hardening[413]: ERROR: cannot parse line: /usr/bin/sudo exactwhitelist

Can cause issues such as this:

How can a systemd unit alone without any others being executed at the very same time?

1 Like

This needs a revision.

systemd unit file to remount /home /tmp /dev/shm /run with nosuid,nodev

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