https://lore.kernel.org/kernel-hardening/20200205223950.1212394-1-kristen@linux.intel.com/
There’s work on making KASLR more fine-grained and resistant to info leaks.
https://lore.kernel.org/kernel-hardening/20200205223950.1212394-1-kristen@linux.intel.com/
There’s work on making KASLR more fine-grained and resistant to info leaks.
What’s the point of the “#### meta start” lines in etc/sysctl.d/30_security-misc.conf?
madaidan via Whonix Forum:
What’s the point of the “#### meta start” lines in etc/sysctl.d/30_security-misc.conf?
To be used in future for auto generation of design documentation. Not
done for subject of security but done for subject of networking. See:
Bluetooth is blacklisted to reduce attack surface. Bluetooth also has a history of security concerns. Bluetooth - Wikipedia
hotwater:
This is a very sharp decision. Many users use bluetooth for different purposes, like bluetooth speakers, mouses, keyboards, and other pieces of hardware.
Although bluetooth had many critical flaws, their core recommendations always admonish how to resist. Like the KNOB vulnerability which had a place on all bluetooth chips 1.0 to 5.1, core specs now say “enforce a minimum encryption key length of 7 octets for BR/EDR connections”.
It’s better to accurately follow the recommendations and not to cut the technology.
Was always wondering if we’d need two more packages. security-misc-vm
(where blocking bluetooth makes sense) and security-paranoid
(more experimental, more likely breaking things, probably non-default, optionally installed package).
The days of hidepid=2
might be counted.
With wayland it will be no longer possible to run applications as root. I.e.lxsudo
will no longer work. Source:
Running GUI applications as root - ArchWiki
Therefore also pkexec wrapper (redirecting to lxsudo) will no longer work. I.e. when using wayland, no more pkexec based applications could be used.
And what’s more important? Wayland or hidepid? I guess wayland. (At some point
Also due to other bugs… cannot use pkexec
madaidan via Whonix Forum:
Merged.
I think it might be better to make hidepid=2
optional now if it’s causing so much breakage.
proc-hidepid.service
can be disabled by default and how to enable it can be added to the wiki.
If System-wide sandboxing framework - sandbox-app-launcher is implemented, then hidepid=2
won’t be as important anymore as most applications can be run in a PID namespace (except the ones that break).
Will revert.
Causing error output during boot of Whonix VirtualBox 15.0.0.9.0-developers-only
. (Happening during initramfs sysctl.)
vm.unprivileged_userfaultfd is an unknown key
That message is very prominent now that other verbose boot messages are disabled.
sudo sysctl -w vm.unprivileged_userfaultfd=0
sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory
Please fix.
That error is harmless and doesn’t do anything. It’s just because our kernel version doesn’t support this feature yet. There’s no point in reverting it.
madaidan via Whonix Forum:
That error is harmless and doesn’t do anything. It’s just because our kernel version doesn’t support this feature yet. There’s no point in reverting it.
The only point of reverting then is avoiding user confusion as this is a
prominent message during waiting for X to finally draw something.
We can just change >/dev/null
to &>/dev/null
in security-misc/sysctl-initramfs at master · Kicksecure/security-misc · GitHub
Then we would miss any errors if this should break.
Then we can change it to &>>${rootmnt}/var/log/sysctl-initramfs.log
to log any actual errors in case of breakage but hide the unimportant ones from the user.
Or maybe:
sysctl -p ${rootmnt}/etc/sysctl.d/*.conf >/dev/null 2> >(grep -v "sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory")
So only the unprivileged_userfaultfd error is hidden.
Something like this maybe. Though the actual error message to grep for is more similar to:
vm.unprivileged_userfaultfd is an unknown key
I didn’t note the exact one.
Also that snippet is broken. Added something else broken to it. (Just a single X in some sysctl config file.) That error would be hidden too with the current snippet.
Maybe redirect stderr to /var/log/sysctl-initramfs-error.log
first, then cat and grep -v? Probably also simpler to read than >(...)
.
/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs is an sh script and >(...)
might be a bash feature. Dunno if bash can be used in initramfs easy/sane[size, dependencies].
That is the actual error message.
sysctl -p test
sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory
“test” being a file that contains vm.unprivileged_userfaultfd=0
.
That sounds good. cat is unneccesary though. We can just use
grep -v "sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory" /var/log/sysctl-initramfs-error.log
Should the content of /var/log/sysctl-initramfs-error.log
be overwritten (>
) or just appended to (>>
)? I think something like this would be best:
sysctl -p ${rootmnt}/etc/sysctl.conf >/dev/null 2>${rootmnt}/var/log/sysctl-initramfs-error.log
sysctl -p ${rootmnt}/etc/sysctl.d/*.conf >/dev/null 2>>${rootmnt}/var/log/sysctl-initramfs-error.log
grep -v "sysctl: cannot stat /proc/sys/vm/unprivileged_userfaultfd: No such file or directory" /var/log/sysctl-initramfs-error.log
The first sysctl command overwrites it to remove past entries and the second appends to it.
Looks different during initramfs in Whonix VIrtualBox 15.0.0.9.3-developers-only. Yes, I am sure. I was also surprised the error message is different in the fully booted system.
Maybe it is for now. Could we skip further error messages in future if required?
What’s the standard? I guess it is >>
? But I am OK with your suggestion (new after each reboot) too. Otherwise we would have to add logrotate too. Full log over multiple reboot probably not worth that effort.