Various Improvement Options

[monsieuremre]

Disabling bluetooth is a bold choice. But if we are concerned about even breaking some random apps when remounting, we should also be concerned about making the system unusable for ordinary people. We can set bluetooth configurations in a way that it starts turned off on boot, it uses private addresses and times out on discoverability. We can also make a systemd service to automatically turn off bluetooth when there are no devices connected for 10 minutes. This is implemented for example in graphene os.

Usb-hardening. We can harden the usage of usb devices with usb-guard. By default blocking everything and whitelisting what was plugged in in the time of install can be a choice. But if we don't want to be that extreme, we can just manually reject some stuff and allow others. For example, as I implemented in my script, the following:

allow with-interface equals { 08:*:* } # Allow usb devices with mass storage interface
reject with-interface all-of { 08:*:* 03:00:* } # These have both storage and keyboard. Suspicious.
reject with-interface all-of { 08:*:* 03:01:* }

This would for example protect from what is reviewed in this video.

Disabling x11 all together, including via xwayland. This requires, of course, the user being on wayland already. For this I suppose, kicksecure and whonix should first make the move to drop x11. Using wayland also means using pipewire, which much better. This option depends on external factors tho, so this is more of an idea only.

I think I can implement these things, considering they are rather simple solutions, If they should be of interest for the maintainers of this repo.

[adrelanos]

Disabling bluetooth is a bold choice. But if we are concerned about even breaking some random apps when remounting, we should also be concerned about making the system unusable for ordinary people.

Right. The amount of breakage we're willing to suffer with security-misc for the sake of improved security isn't well defined. Happy to hear suggestions.

I guess with bluetooth in the age of widespread bluetooth keyboard and mice it's unreasonable to break it by default.

We can set bluetooth configurations in a way that it starts turned off on boot, it uses private addresses and times out on discoverability. We can also make a systemd service to automatically turn off bluetooth when there are no devices connected for 10 minutes. This is implemented for example in graphene os.

Nice.

Usb-hardening. We can harden the usage of usb devices with usb-guard.

It's in Debian...
https://packages.debian.org/bookworm/usbguard
That helps.

By default blocking everything and whitelisting what was plugged in in the time of install can be a choice.

Sounds cool. I have no experience yet with this.

But if we don't want to be that extreme, we can just manually reject some stuff and allow others. For example, as I implemented in my script, the following:

allow with-interface equals { 08:*:* } # Allow usb devices with mass storage interface
reject with-interface all-of { 08:*:* 03:00:* } # These have both storage and keyboard. Suspicious.
reject with-interface all-of { 08:*:* 03:01:* }

Seems harder to implement, maintain, document, user support...

Disabling x11 all together, including via xwayland. This requires, of course, the user being on wayland already. For this I suppose, kicksecure and whonix should first make the move to drop x11. Using wayland also means using pipewire, which much better. This option depends on external factors tho, so this is more of an idea only.

pipewire is general Kicksecure development. I mean, outside of security-misc. That is pretty much done. It that part is already in the developers repository and coming in the next point release. Reference:
https://forums.whonix.org/t/port-from-pulseaudio-to-pipewire-for-audio-support/16879

Wayland is quite harder... I don't know the way forward. See:
https://forums.whonix.org/t/port-to-wayland/17380

I think I can implement these things, considering they are rather simple solutions, If they should be of interest for the maintainers of this repo.

Yes, please.

[monsieuremre]

Wayland is quite harder... I don't know the way forward. See:

It may just be the time for whonix to embrace KDE again just like it once did. That being said, kicksecure being shipped with xfce would be really really bad. A VM is one thing. But using the pre-historic insecure x protocol on a personal desktop would be unsound. Security & privacy benefits of wayland over x11 are really too many.

[adrelanos]

monsieuremre:

> Wayland is quite harder... I don't know the way forward. See: It may just be the time for whonix to embrace KDE again just like it once did.

re-considered here: https://forums.whonix.org/t/kde-wayland-support/17429

[monsieuremre]

Since we have modified home_folder_access_rights_lockdown to work for all users with all usernames all the time, I don't see any reason to require the user to have a user user in the sudo group. This rule is still enforced on package install. This could and should be removed I think. Is there any other reason to keep this condition that I do not know of?

[adrelanos]

Since we have modified home_folder_access_rights_lockdown to work for all users with all usernames all the time, I don't see any reason to require the user to have a user user in the sudo group. This rule is still enforced on package install. This could and should be removed I think. Is there any other reason to keep this condition that I do not know of?

answered here:
#155

[monsieuremre]

Since there has been a number of new pull requests lately, I think I can point out the ones that are the most easy to review and merge/reject, so that you can prioritize them to clean them up.

• Bluetooth and WiFi Patch done and ready to go, simple configs really.
• SysRq thing is a very minor change and should be easy to review, also ready to go.
• Thunderbird hardening is also very small and easy to review. Only thing would be deciding if you want them or not in the scope of this project.
• The module loading service is also completely ready to go and tested, but more complicated. But you already reviewed most anything there, I believe.

[monsieuremre]

How much work would it require to package this source as an .rpm? I would really like to test this on opensuse. I can also a tool like alien, but a native solution would be better, like if this package supported building as an rpm. Would this be merged if I implement it?

[adrelanos]

These should all be answered.

[adrelanos]

https://forums.whonix.org/t/kernel-hardening-security-misc/7296/524

[adrelanos]

• stop leaking PIDs, command line arguments, UID, GID through systemctl, D-Bus interface / API - hidepid compatibility systemd/systemd#29893

[monsieuremre]

Closing this one, new ones will follow.

[adrelanos]

https://forums.whonix.org/t/dm-verity-for-debian-whonix/17216/6

mkosi supports:

• dm-verity
• Discoverable Partitions Specification (DPS) (why remount-secure even needed? fix insecure mount options at the root, not here #157 (comment))

Updated images could perhaps be deployed through an A/B update engine: systemd-sysupdate

But first thing first. Learning, feasibility and porting to mkosi (initially without dm-verity as this isn't a simple "enable in the config" thing) will take time, is part of derivative-maker, not security-misc.