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
What creates system-map files and can we suppress creation rather than deleting those?
We delete those but that doesn’t help much if these get created later on. Better prevent creation than “only” deleting.
When compiling the kernel, it generates system.map files. The kernel package likely puts them into /boot so we’d have to modify the package if we want to suppress the creation of them.
They get deleted at boot by a systemd service. If they get created later on, they’d get deleted next boot.
Which means there’s a time gap between re-creation and re-deletion which
could be abused even by chance by malware.
Could you look please if you can find the code which generates these
files? Maybe there is a config option already to disable it. And if not,
we could request it from upstream.
The actual compilation generates them. I can’t find what places them in /boot though.
3 posts were split to a new topic: allow loading signed kernel modules by default / disallow kernel module loading by default
Instead of trying to get rid of this time gap altogether which as far as I know, isn’t doable, we could attempt to reduce it as much as possible.
We could configure remove-system-map.service to execute our script every few minutes. This can be done by adding
Restart=always
RestartSec=5m
which would make it run every 5 minutes.
This would flood the systemd logs with “Starting remove-system-map.service” type messages though.
Alternatively, we could configure a cron job to execute our script every few minutes.