Kernel Hardening - security-misc

New warning in journal:

Sep 14 08:14:14 host systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument

Possible cause:

I am not sure above bug is only a symptom. I don’t think we changed fs.file-max?

1 Like

I’ve looked through it before and I don’t think there’s anything useful to us.

Yes, /etc/sysctl.d/anonymizer-config-gateway.conf changes it although it’s nothing to do with kernel hardening.

1 Like

Interesting conclusion about syzbot in the Linux Plumbers conference attended by a Debian kernel maintainer

Q: How often does this catch bugs in the distro kernel?

A: It doesn’t often catch new bugs but does catch missing fixes and regressions.

Q: Is anyone checking the syzkaller test cases against backported fixes?

A: Yes [but it wasn’t clear who or when]

2 Likes
2 Likes
2 Likes

Outreach done to:


(as per enforce kernel module software signature verification [module signing] / disallow kernel module loading by default - #47 by Patrick)

2 Likes

Could we please work on the presentation of package security-misc?

Contributions / suggestions for README.md?
Github description, github website, githab tags?

Technical implementation is good but presentation might be lacking and outreach and popularity of security-misc is almost non-existing.

Once that is done, we could notify related parties of the existence of this package and add to relevant lists.

2 Likes

Should review generally which systemd target pulls services. Some services make much more sense (better security) when run during sysinit target before anything else that might get exploited later on (desktop environment, browser, web servers, etc.)

1 Like

Quote Lennart Poettering (systemd developer) said in 2014

Sorry, but we simply don’t support hidepid= as it is implemented right now in the kernel. We need to be able to get meta data out of /proc for clients. journald needs that, polkit, does, our apis do that, there’s probably a lot more.

hidepid= is a bit naive there.

I’d actually like to support it better, but if we do that I figure we need some kernel changes first. instead of being a kernel-wide setting it should be a per-mount point setting, so that we can turn it on for some services, and turn it off for others, simply by passing different settings to the procfs in their respective mount namespaces.

Anyway, the way it stands now, we cannot support this. Sorry.

That quote is a bit old. Things may or may not be better by now.

1 Like

No, it’s still the same. things like logind usually do need an exception but proc-hidepid.service always executes after them so it’s not that bad.

1 Like

During boot, the kernel logs are displayed on the console. As the kernel logs are meant to be restricted to root (kernel.dmesg_restrict=1), this should probably be disabled.

Setting kernel.printk=3 3 3 3 with sysctl configures it so only really important errors will be displayed.

Also see Does printk() cause any security issues?

This can improve boot and shutdown speed too. I’ve noticed that performance improves significantly after setting this.

1 Like

Not sure exactly how to solve this but something should be done.

Was contemplating:

dmesg --console-off

Where/when to run that command? That command is per console or user or global?

The context which pointed that out: timesync Error: vgsvcTimeSyncWorker: VbglR3GetHostTime failed - #7 by Patrick_mobile

Also whonixcheck needs lockdown wrt log viewing. Allows users to see log on systemd warning/error/cycle messages. Running whonixcheck should require sudo but as much as possible should run unprivileged.

1 Like

I still see some logs after running that. Changing the kernel.printk sysctl hides more. I can still see some logs even with changing kernel.printk as it starts displaying logs before systemd-sysctl is executed. The only way around that would be setting kernel.printk in the initramfs, before systemd has started if it’s even possible.

During security-misc installation and/or a systemd service.

Looks global.

Logs can still be viewed with sudo dmesg. They were never available to unprivileged users in the first place as Debian sets kernel.dmesg_restrict=1 by default.

sudo helps?

1 Like

I guess that’s ok? Unavoidable? At least sudo/root required.

But whonixcheck shouldn’t show to nonroot/nonsudo users.

1 Like

Might be cause or related…?

https://github.com/Whonix/grub-output-verbose/blob/master/etc/default/grub.d/30_output_verbose.cfg

I considered verbose boot a usability feature. Better progress report during boot. Doesn’t look frozen. A lot users think it’s frozen and give up. Also good for debugging / see issues. Might have to reconsider / find alternative.

1 Like

No. I ran it as root.

It wouldn’t be too hard to make it only display the logs if the user is root.

1 Like

Under the enhanced threat model of hiding as much information from user as possible, user has no business reading most of whonixcheck output. But nontrivial change since whonixcheck also used as connectivity checker / progress meter after ACW.

1 Like

Perhaps specifically those are ones that should better be hidden? If anything, hide it all for completeness sake?

1 Like

If really important errors are hidden too then users might just see a black screen and have no idea what’s happened.

E.g. a kernel panic happens for whatever reason and important errors are hidden so the user doesn’t know.

1 Like