Outreach done to:
- Debian -- Details of package lockdown in buster
- Debian -- Details of package hardening-runtime in buster
Outreach done to:
Could we please work on the presentation of package
Contributions / suggestions for
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.
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.)
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.
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.
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.
kernel.printk=3 3 3 3 with sysctl configures it so only really important errors will be displayed.
This can improve boot and shutdown speed too. I’ve noticed that performance improves significantly after setting this.
Not sure exactly how to solve this but something should be done.
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.
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.
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.
I guess that’s ok? Unavoidable? At least sudo/root required.
But whonixcheck shouldn’t show to nonroot/nonsudo users.
Might be cause or related…?
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.
No. I ran it as root.
It wouldn’t be too hard to make it only display the logs if the user is root.
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.
Perhaps specifically those are ones that should better be hidden? If anything, hide it all for completeness sake?
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.
sudo make install
make -C /lib/modules/4.19.0-6-amd64/build M=/home/user/sourcesother/lkrg-0.7 modules_install
make: Entering directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
Warning: modules_install: missing ‘System.map’ file. Skipping depmod.
make: Leaving directory ‘/usr/src/linux-headers-4.19.0-6-amd64’
[*] Executing LKRG’s bootup installation script
[+] Systemd detected
Installing lkrg.service file under /run/systemd/system folder
Enabling lkrg.service on bootup
Created symlink /etc/systemd/system/multi-user.target.wants/lkrg.service → /run/systemd/system/lkrg.service.
To start lkrg.service please use: systemctl start lkrg
We should use the
init_on_free=1 boot parameters once they get to the Debian stable kernel.
init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes.
init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn’t leak via use-after-free accesses.
I am not sure what the difference between
page_poison=1 is. They seem to do the same.
The link above says
If either SLUB poisoning or page poisoning is enabled, we disable
init_on_alloc and init_on_free so that initialization doesn’t interfere
So I’m not sure which to use.
There is a Tails ticket for this Enable the init_on_alloc=1 and init_on_free=1 Linux options (#17236) · Issues · tails / tails · GitLab and they also use
page_poison=1 so we should wait and see what they say.
linux-hardened seems to prefer init_on_free over page_poison.
The program doesn’t work for me but it has a neat list of areas to look for kernel symbols.
I can’t find any kernel symbol leaks in these directories/files but it lists the kernel images and I don’t know how to check those for symbols.
Why are the kernel images readable by all users anyway? Shouldn’t it be restricted to root?
Linus Torvalds has also said interesting things about these leaks.
And yes, as Kees and Daniel mentioned, it’s definitely not just dmesg. In fact, the primary things tend to be /proc and /sys, not dmesg itself.
Another example of this would be commit 31b0b385f69d (“nf_conntrack: avoid kernel pointer value leak in slab name”), where the fact that the slab name had a pointer in it leaked it in the filenames in /sys, because we export slab statistics under /sys/kernel/slab/. And each file was readable only by root, but the file names were readable by everybody.
The full system apparmor profile gives fine-grained access to /sys and /proc so that would make kernel pointer leaks very unlikely.