Wifi and Bluetooth Patch | Security and Privacy

[monsieuremre]

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]

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]

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]

This isn't needed. There are no conf files in /bin/. rm_conffile is only useful for /etc because these files are treated in a special way by dpkg.

[monsieuremre]

I did not know this. Makes sense.

[adrelanos]

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]

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]

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]

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]

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]

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]

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]

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]

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

[monsieuremre]

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]

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]

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]

• fix Bluetooth readme #180

[adrelanos]

reverted network changes as per:

• MAC randomization breaks root server and VirtualBox DHCP / IPv6PrivacyExtensions might be problematic #184

(Bluetooth unaffected.)