Kernel Hardening

Qubes Debian VM with Qubes dom0 kernel.

sudo checksec --kernel
  • Kernel protection information:

    Description - List the status of kernel protection mechanisms. Rather than
    inspect kernel mechanisms that may aid in the prevention of exploitation of
    userspace processes, this option lists the status of kernel configuration
    options that harden the kernel itself against attack.

    Kernel config:

    Vanilla Kernel ASLR: Full
    Protected symlinks: Enabled
    Protected hardlinks: Enabled
    Ipv4 reverse path filtering: Disabled
    Ipv6 reverse path filtering: Disabled
    Kernel heap randomization: Enabled
    GCC stack protector support: Enabled
    GCC structleak plugin: Enabled
    GCC structleak by ref plugin: Enabled
    SLAB freelist randomization: Enabled
    Virtually-mapped kernel stack: Enabled
    Enforce read-only kernel data: Enabled
    Enforce read-only module data: Enabled
    Exec Shield: Disabled

    Hardened Usercopy: Enabled
    Hardened Usercopy Pagespan: Disabled
    Harden str/mem functions: Enabled
    Restrict /dev/mem access: Enabled
    Restrict I/O access to /dev/mem: Enabled
    Restrict /dev/kmem access: Enabled

  • X86 only:
    Address space layout randomization: Enabled

  • SELinux: Disabled

    SELinux infomation available here:

  • grsecurity / PaX: No GRKERNSEC

    The grsecurity / PaX patchset is available here:

1 Like

Same in Qubes Debian VM with Qubes VM kernel.

1 Like


Probably kernel recompilation required? -> kernel recompilation for better hardening

1 Like

Hardened usercopy pagespan is only good for debugging AFAIK.

1 Like
1 Like

5 posts were split to a new topic: enable reverse path filtering

Something we don’t have yet here?

1 Like

Doesn’t seem to have anything we don’t have.

1 Like

Also, some systems don’t store the System.map file in /boot but in files such such as /lib/modules/*/*/System.map or /usr/src/*/System.map.

If we were to remove read access to kernel images in /boot for non-root users, then we’d also need to remove read access to files like /usr/src/*/vmlinux and /vmlinuz.


Instead of porting opensuse’s stuff to Debian, we can make our own simpler solution like https://paste.debian.net/hidden/7800cde6/

Config files would look like https://paste.debian.net/hidden/249ee00b/

1 Like

Commented inline on github.

Really good approach.

(Although might have some nitpicks. mywiki.wooledge.org might say for line in $(cat ${config_file}) isn’t secure. Never mind. Please send a pull request. I’ll add any parsing enhancements on top.)

dpkg-statoverride should be used, though. Ideally as replacement for chmod/chown - if that is possible. But surely in combination with dpkg-statoverride. Because when packages are updated, these permissions will be reset- By using dpkg-statoverride, permissions will always be consistent what we want - even if packages are updated.


I was testing around with file capabilities and did some grep hackery to add a [Capabilities] sections where we can specify file capabilities.

What do you think of https://paste.debian.net/hidden/657725a9/?

Example of a config file: https://paste.debian.net/hidden/feee6217/


while read line; do command; done <${config_file}

be better?

Should it also use a systemd service so these permissions are always set at boot regardless?

If users need to, they can disable the service or add a permission-hardening.d file for custom permissions.

1 Like

It’s a good list, and as @madaidan said, Whonix implements pretty much all of it. We do not have separate partitions, but we restrict the permissions.With restricted root and the other Whonix protections, there is good security.


Probably better to add an optional 5th column https://paste.debian.net/hidden/4fd3aaee/

Example: https://paste.debian.net/hidden/332b8300/



A much better script https://paste.debian.net/hidden/a1b89eb1/

1 Like

The advantage here would be we can just copy/paste the suse config file and don’t need yo modify it? Please add a source comment.
And then we could add our own config file in addition if we need to extend it?

if ! dpkg-statoverride --list | grep -q "${owner} ${group} ${mode:1} ${file%/}"; then

How would dpkg-statoverride update existing entries then if permissions changed in config? Maybe better to remove that line or improve of that’s feasible, not too much effort?

1 Like

Could be. Considered bonus feature.

Not doable using systemd tmpfiles.d due to capabilities?

Sounds great!

1 Like

madaidan via Whonix Forum:


while read line; do command; done <${config_file}

be better?


1 Like

I think it would be better to create our own.

You can’t update them either way.

dpkg-statoverride will fail with an error:

dpkg-statoverride: error: an override for '/bin/true' already exists; aborting

We’d need to make it remove the entry then add it with the new permissions.

If this line was removed, dpkg-statoverride would spam a bunch of errors.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]