[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Kernel Hardening

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.

2 Likes
1 Like

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:

1 Like
2 Likes

disrupt_the_flow

Bluetooth is blacklisted to reduce attack surface. Bluetooth also has a history of security concerns. https://en.wikipedia.org/wiki/Bluetooth#History_of_security_concerns

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).

2 Likes

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:

https://wiki.archlinux.org/index.php/Running_GUI_applications_as_root#Wayland

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

3 Likes

madaidan via Whonix Forum:

https://github.com/Whonix/security-misc/pull/65

Merged.

1 Like

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 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).

2 Likes
1 Like

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.

1 Like

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.

1 Like

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.

1 Like

We can just change >/dev/null to &>/dev/null in https://github.com/Whonix/security-misc/blob/master/etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs

1 Like

Then we would miss any errors if this should break.

1 Like

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.

1 Like

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.

1 Like

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].

1 Like

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.

1 Like

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.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]