From: Jeff Vander Stoep <jeffv@xxxxxxxxxx> Date: Wed, 21 Aug 2019 15:45:47 +0200 > MAC addresses are often considered sensitive because they are > usually unique and can be used to identify/track a device or > user [1]. > > The MAC address is accessible via the RTM_NEWLINK message type of a > netlink route socket[2]. Ideally we could grant/deny access to the > MAC address on a case-by-case basis without blocking the entire > RTM_NEWLINK message type which contains a lot of other useful > information. This can be achieved using a new LSM hook on the netlink > message receive path. Using this new hook, individual LSMs can select > which processes are allowed access to the real MAC, otherwise a > default value of zeros is returned. Offloading access control > decisions like this to an LSM is convenient because it preserves the > status quo for most Linux users while giving the various LSMs > flexibility to make finer grained decisions on access to sensitive > data based on policy. > > [1] https://adamdrake.com/mac-addresses-udids-and-privacy.html > [2] Other access vectors like ioctl(SIOCGIFHWADDR) are already covered > by existing LSM hooks. > > Signed-off-by: Jeff Vander Stoep <jeffv@xxxxxxxxxx> I'm sure the MAC address will escape into userspace via other means, dumping pieces of networking config in other contexts, etc. I mean, if I can get a link dump, I can dump the neighbor table as well. I kinda think this is all very silly whack-a-mole kind of stuff, to be quite honest. And like others have said, tomorrow you'll be like "oh crap, we should block X too" and we'll get another hook, another config knob, another rulset update, etc.
