That doesn’t work as there is no /lib/systemd/system/tmp.mount file.
(re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?
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
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
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”).
After=local-fs.target but it lacks
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.
? Dunno if that would require using
--rbind. Looks like what we want is
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?
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
Fixes (noexec) and enhancements in git master and developers repository.
The “Filesystem layout and structuring” section has a table on which directories to use restrictive mount options on.
Quote Kernel Hardening
/usr/lib/security-misc/remount-secure. Should now be quite easy to add new remounts.
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
These two things must not run together.
Dec 29 04:17:12 debian-buster-test remount-secure: mount -o nosuid,nodev --bind /tmp /tmp
Dec 29 04:17:12 debian-buster-test permission-hardening: /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: 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?
This needs a revision.
systemd unit file to remount /home /tmp /dev/shm /run with nosuid,nodev