search

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
518 stars 51 forks source link

Wifi and Bluetooth Patch | Security and Privacy #145

Closed monsieuremre closed 1 year ago

monsieuremre commented 1 year ago

With this patch, the mac address of the device is randomized per wifi connection. This randomizes all the bits and does not hide the fact that we are randomizing the address. The original mac is not extractable and this does not cause any issue. The same functionality exists in grapheneOS.

The privacy extensions for ipv6 addresses are also enabled. These are theoretically not necessary when we randomize the mac address. But they are still harmless and bring privacy. Unlike ip4 addresses, ipv6 addresses can also leak device information and not only network.

And also, disabling the kernel bluetooth modules was a little too much for daily usage for most people in this age. So I disabled it and configured bluetooth in a privacy respectin manner. Bluetooth starts disabled on start up. This wasn't the case in a default install. Temporary devices are forgotten immediately. Enforces private addresses. Some legacy devices that don't support private addresses are not accepted. There is a timeout for pairability and discoverability, unlike the default configs. I see this as good enough. Bluetooth is turned off on boot. User has the freedom to enable it using their GUI settings at their own risk.

On file was deleted. It is also addressed in the main script. Lines are not deleted, just commented out with the proper explanation.

adrelanos commented 1 year ago

As per FHS and/or other conventions for a package / distribution /etc shouldn't be used (for local system admin) but at least for systemd some other location such as /lib or /usr/lib should be used. Could you research that please and move accordingly?

Not sure about network manager. For that, /etc might be correct.

monsieuremre commented 1 year ago

I changed the path for those that I could. There is only /etc/bluetooth/30_security-misc.conf left. Reading the man page, I gather this is the only valid path for a config file for bluetooth. We can specify a different path by modifying the bluetooth service and adding ExecStart=/usr/lib/bluetooth/bluetoothd --configfile /our/file. This would intruduce unnecessary complexity. So this should be left as is in /etc in my opinion.

adrelanos commented 1 year ago

Agreed. Seems already reasonable.

I don't like the 99 prefix as a number. Because as we've seen with /usr/lib/sysctl.d/99-protect-links.conf it is difficult to overrule these.

Not a big deal. If you like, I can adjust the numbers after merge.

adrelanos commented 1 year ago

The rest seems good at first sight. But not yet tested.

Did you test this?

Could you please send a PR to update debian/control? (Can be a separate PR or the same one. That's not important.)

monsieuremre commented 1 year ago

The rest seems good at first sight. But not yet tested.

Did you test this?

I had tested everything when they were under /etc. But I read in their man pages that these paths are also parsed and equally valid for config files to be in. So I think they should work, but not explicitly tested.

monsieuremre commented 1 year ago

Could you please send a PR to update debian/control? (Can be a separate PR or the same one. That's not important.)

I don't see what I would change in this file.

monsieuremre commented 1 year ago

Agreed. Seems already reasonable.

I don't like the 99 prefix as a number. Because as we've seen with /usr/lib/sysctl.d/99-protect-links.conf it is difficult to overrule these.

Not a big deal. If you like, I can adjust the numbers after merge.

I chose this because I thought it would be better if get parsed the last. So I thought of it as giving them more priority. I don't know if my thinking was correct. You can edit the names to your liking after merge.

adrelanos commented 1 year ago

monsieuremre:

Could you please send a PR to update debian/control? (Can be a separate PR or the same one. That's not important.)

I don't see what I would change in this file.

Under Description: describing the bluetooth implementation. And maybe some other stuff recently changed.

monsieuremre commented 1 year ago

Under Description: describing the bluetooth implementation. And maybe some other stuff recently changed.

I think that and also the readme are now already out of date. And they are going to become more out of date with the recent pull request being merged. A better approach would be updating these at once with another pull request. So I think you can merge this one, if everything else seems ok to you.

adrelanos commented 1 year ago

monsieuremre:

Under Description: describing the bluetooth implementation. And maybe some other stuff recently changed.

I think that and also the readme are now already out of date. And they are going to become more out of date with the recent pull request being merged. A better approach would be updating these at once with another pull request. So I think you can merge this one, if everything else seems ok to you.

My mistake. debian/control Description: isn't used much for security-misc to avoid duplication and due to its size

Only README.md needs updating.

monsieuremre commented 1 year ago

I will create a pull with a readme update for everything so far once we got most stuff merged and activated.

monsieuremre commented 1 year ago

I think we are ready to merge this one. If there are problems or features that are not wished, I can fix/undo them.

adrelanos commented 1 year ago

I cannot really test this as I don't even have any Bluetooth devices. But I guess this is better than completely disabling Bluetooth.

monsieuremre commented 1 year ago

You can at least test the MAC address thing I guess? See your MAC get changed on every new connection. IPv6 privacy extensions are also enabled, which actually, when randomizing the mac address, IPv6 gets private anyway. But yeah.

adrelanos commented 11 months ago
adrelanos commented 10 months ago

reverted network changes as per:

(Bluetooth unaffected.)