Kernel Hardening - security-misc

Development
256

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:
    /proc/config.gz

    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:
    http://selinuxproject.org/

  • grsecurity / PaX: No GRKERNSEC

    The grsecurity / PaX patchset is available here:
    http://grsecurity.net/

1 Like
257

Same in Qubes Debian VM with Qubes VM kernel.

1 Like
258

False-positives.

Probably kernel recompilation required? → kernel recompilation for better hardening

1 Like
259

Hardened usercopy pagespan is only good for debugging AFAIK.

1 Like
260
1 Like
261

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

262

Something we don’t have yet here?

1 Like
263

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

1 Like
264

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.

2 Likes
265
2 Likes
266

Instead of porting opensuse’s stuff to Debian, we can make our own simpler solution like Debian paste error

Config files would look like Debian paste error

1 Like
267

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.

2 Likes
268

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 Debian paste error?

Example of a config file: Debian paste error

Would

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
269

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.

2 Likes
270

Probably better to add an optional 5th column Debian paste error

Example: Debian paste error

https://phabricator.whonix.org/T522

2 Likes
271

A much better script Debian paste error

1 Like
272

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
273

Could be. Considered bonus feature.

Not doable using systemd tmpfiles.d due to capabilities?

Sounds great!

1 Like
274

madaidan via Whonix Forum:

Would

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

be better?

Yes.

1 Like
275

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