(re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?
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
/run/user/1000 bypasses /run’s
noexec as it is its own mount point. We might want to look into restricting that too.
It could be useful to mount /dev with
We should experiment with the
ro mount option to mount directories as read-only. /sys would be a good one for this as most things don’t need to write to it.
More mount points we can restrict are:
mqueue on /dev/mqueue type mqueue (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
CLIP OS’s fstab is here https://github.com/clipos/products_clipos/blob/master/core/configure.d/40_fstab.sh
I can merge that but it won’t help much. The current implementation is a dead-end. It’s needs to be replaced entirely. See my previous post. There I link to my question, the bug description and reply by systemd.
The 2 alternative methods talked about in that link are using /etc/fstab or systemd .mount files. We’ve already looked into both of these when creating proc-hidepid and neither worked for us.
Then we need to produce good questions and ask the systemd developers more. The current implementation is a dead-end indeed. My question on the mailing list perhaps doesn’t reflect it how bad it is. It causes horrible race conditions. Hard to debug. Random things break at random time. It’s really not ready for production.
The race conditions can be fixed by scrapping the systemd service and running it in the initramfs. This also goes in line with what the guy on the mailing list said:
Have it run before systemd (i.e. do it from the initramfs)
How would debugging be a problem? Make a list of everything it does and write it to /var/log/remount-secure.log.
What remount-secure does is easy to log indeed. That always worked. What was hard to debug was some random unrelated service breaking.
That would be a good solution.
Before piling up more and more initramfs stuff, could you port all of Whonix to dracut and implement this using a dracut hook?
I’ve no experience with dracut and an initramfs-tools hook would still be needed even if we do switch to dracut, for ordinary Debian compatibility as security-misc isn’t Whonix-specific.
dracut is a replacement for initramfs-tools if I am not mistaken.
initramfs-tools hooks would need to be replaced by a dracut hook.
Yes, but normal Debian users won’t be using dracut so we’d need to have hooks for both so they can still use security-misc.
Also normal Debian users can use dracut. It’s a well supported Debian package. Dunno which initramfs generator is default for Deiban now or in future initramfs-tools vs dracut.
I am not sure how much it’s worth spending effort on supporting security-misc for plain Debian, non-Kicksecure users.
Linux user account hardening (pam, su, sudo) is causing trouble.
- at least 1 user needs to be in group
sudo- otherwise security-misc aborts installation
- previous manual pam modifications can break:
That could be a lot effort for a small number of users.
initramfs-tools hooks are trivial. It’s a minor thing that would make security-misc far more compatible.
I figured it out.
Now we just need to figure out how to get the /tmp, /dev/shm and /run restrictions to work.