Doesn’t seem to be anything useful there.
1 Like
This is a good presentation on how many bugs the Linux kernel has and is why kernel hardening is so important.
TL;DR: Hundreds of bugs are found every month with fuzzers.
1 Like
A post was split to a new topic: Disabling TCP SACK, DSACK, FACK
Something we don’t have yet here?
1 Like
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:
- Debian -- Details of package lockdown in buster
- Debian -- Details of package hardening-runtime in buster
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