Should security-misc also disable coredumps? For distros that have them enabled by default.
It wouldn’t be needed on Whonix as Debian disables them by default and Whonix doesn’t re-enable them but it may be useful for other distros that are using security-misc.
Awesome! Will test soon.
madaidan via Whonix Forum:
I can add systemd sandboxing if needed (likely not).
I am wondering if systemd sandboxing can do more harm than good here.
What’s the threat model? /proc containing at early boot something
malicious, which would upon using mount with remount options, result
in exploiting a vulnerability in mount, then leading to root compromise?
On the other hand, any (distribution) upgrade of kernel, mount or any
dependent libraries requiring any new seccomp could lead to remount fail
“in the middle”, hence end up with an unbootable system?
madaidan via Whonix Forum:
Should security-misc also disable coredumps? For distros that have them enabled by default.
Yes, that would be good.
As per
security-misc will in future be available in Qubes Debian and Fedora
templates. Perhaps even in Qubes dom0. I.e. Fedora packaging upcoming.
And as per Whonix Packages for Debian Hosts and Whonix Host Enhancements
packages by Whonix can potentially be installed on any derivative of
Debian. If/when security-misc gets ever uploaded to packages.debian.org,
it will flow down to any derivative based on Debian.
I just think we should sandbox as much as possible, especially root processes. A compromised systemd service could pretty easily be turned into a rootkit.
That’s unlikely as I doubt mount will be updated much and this is what testers versions are for. Any major kernel update will likely be part of the testers only version of Whonix. I could remove the syscall filter so it’d be even more unlikely for it to break.
Ok, I’ll add it now.
3 posts were split to a new topic: Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability
In Qubes Debian based AppVM:
sudo mount | grep proc
proc on /proc type proc (rw,relatime,hidepid=2)
It has hidepid but it does not have nosuid,nodev,noexec. Any idea what that is?
When I manually run
sudo /bin/mount -o remount,nosuid,nodev,noexec,hidepid=2 /proc
that works.
mount | grep proc
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime,hidepid=2)
When I disable systemd hardening, there will be all mount options (nosuid,nodev,noexec,hidepid=2) upon systemctl daemon-reload and systemctl restart.
There are zero complaints in journal while systemd hardening is enabled which makes this really hard to debug.
I have to comment out most of them to get all mount options.
#ProtectSystem=strict
#ProtectHome=true
#ProtectKernelTunables=true
#ProtectKernelModules=true
#ProtectControlGroups=true
#PrivateTmp=true
#PrivateMounts=true
#PrivateDevices=true
PrivateNetwork=true
#MemoryDenyWriteExecute=true
NoNewPrivileges=true
RestrictRealtime=true
SystemCallArchitectures=native
#RestrictNamespaces=true
#SystemCallFilter=mount munmap access read open close stat fstat lstat mmap mprotect brk rt_sigaction rt_sigprocmask execve readlink getrlimit getuid getgid geteuid getegid statfs prctl arch_prctl set_tid_address newfstatat set_robust_list openat mkdir
It’s hard to identify which one is the offending one. Could be multiple or some combination that don’t work.
Also I would like to rehash if it’s really worth it. Is what we are doing different from what systemd or other default services are doing (use mount) which are not using that kind of hardening?
It might be PrivateMounts=true. Try uncommenting just that.
Most default systemd services use hardening by default. See inside /lib/systemd/system/systemd-logind.service for example. I find it unlikely that whatever systemd uses for mounting doesn’t use hardening also.
Tried that earlier already (the only one that looks kinda obvious) and did not help. Literally needed to disable “most” to make it work.
That’s weird. Are you sure all of those need to be disabled?
madaidan via Whonix Forum:
Are you sure all of those need to be disabled?
I could have let enabled three of them or so without breaking the mount
feature. Since that seemed wrong, I disabled all of it.
We should at least keep PrivateNetwork=true. That gets rid of all network access from the service which would reduce the chance of somebody exploiting it. Weird that Qubes is the only one breaking from this.
Ok, that works.
4 posts were split to a new topic: set oops=panic kernel parameter or kernel.panic_on_oops=1 sysctl for better security