Kernel Hardening - security-misc

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)

1 Like

When I disable systemd hardening, there will be all mount options (nosuid,nodev,noexec,hidepid=2) upon systemctl daemon-reload and systemctl restart.

1 Like

There are zero complaints in journal while systemd hardening is enabled which makes this really hard to debug.

1 Like

I have to comment out most of them to get all mount options.

#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?

1 Like
1 Like

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.

1 Like

That’s weird. Are you sure all of those need to be disabled?

1 Like

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.

1 Like

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

4 posts were split to a new topic: Disable SUID Binaries

2 posts were merged into an existing topic: Allow multiple flashproxy ports

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.

1 Like

When compiling the kernel, it generates 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.

1 Like

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.

1 Like

The actual compilation generates them. I can’t find what places them in /boot though.

1 Like

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


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.