From: Jeff Vander Stoep <redacted>
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 <redacted>

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.