Hi Joshua,
Thank you for responding.
The intent is not to hide the MAC address from the local-area-network, it is to restrict which applications on the local machine have access to it. The use-case is to more tightly sandbox untrusted applications from accessing persistent hardware identifiers.
Consider a web client application that has a legitimate reason to access the internet and network information in order to retrieve information from a remote web server. Unbeknownst to the user, the application reads the MAC address and sends it to the web server to uniquely identify/fingerprint the hardware that its running on (instead of using more privacy-friendly non-persistent methods like cookies, certificates, temp files, username/password). Tracking with persistent identifiers such as the MAC address is surprisingly common, invisible to the user, and it allows for tracking that persists across multiple users, different networks, history wipes, disk wipes, factory resets, username/password changes etc. The ability to limit access to persistent hardware identifiers like the MAC address allows for writing policy that enhances user privacy by making it more difficult for software to tie itself to specific hardware. Many applications need network access, very few need the MAC address. It would be useful to be able to write policy that allows access to one without the other.
On Wed, Oct 8, 2014 at 6:01 PM, Joshua Brindle <brindle@xxxxxxxxxxxxxxxxx> wrote:
On Wed, Oct 8, 2014 at 8:41 PM, Jeffrey Vander Stoep <jeffv@xxxxxxxxxx> wrote:
> First time poster to the list. I would appreciate feedback/suggestions
> regarding the following patch.
>
> This patch which provides SELinux control over network interface MAC
> addresses. This patch allows access to the MAC address to be controlled by
> policy. Network MAC addresses are a long lived unique device identifier, and
> a security policy may wish to control access to the identifier without
> further limiting network use, perhaps for privacy reasons.
>
> The existing SE Linux permissions are too coarse in that they only allow
> blanket read/no-read access to this socket ioctl. We would like to consider
> both the read/no-read permission as well as an additional permission that
> checks the ioctl cmd argument. This allows applications to continue
> accessing the IP address, netmask, etc, while being denied access to the MAC
> address.
>
If someone has another system on the same network they can just get
the address by pinging it and running arp -a, right?
What use case do you see covering by adding this permission?
> _______________________________________________
> Thanks,
> Jeff Vander Stoep
>
> ---
> security/selinux/hooks.c | 7 +++++++
> security/selinux/include/classmap.h | 2 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 1e1266b..cb65fd9 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3142,6 +3142,13 @@ static int selinux_file_ioctl(struct file *file,
> unsigned int cmd,
> SECURITY_CAP_AUDIT);
> break;
>
> + case SIOCGIFHWADDR:
> + error = file_has_perm(cred, file, FILE__IOCTL);
> + if (error)
> + break;
> + error = file_has_perm(cred, file, SOCKET__GET_HWADDR);
> + break;
> +
> /* default case assumes that the command will go
> * to the file's ioctl() function.
> */
> diff --git a/security/selinux/include/classmap.h
> b/security/selinux/include/classmap.h
> index c32ff7b..306f0d2 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -7,7 +7,7 @@
>
> #define COMMON_SOCK_PERMS COMMON_FILE_SOCK_PERMS, "bind", "connect", \
> "listen", "accept", "getopt", "setopt", "shutdown", "recvfrom", \
> - "sendto", "recv_msg", "send_msg", "name_bind"
> + "sendto", "recv_msg", "send_msg", "name_bind", "get_hwaddr"
>
> #define COMMON_IPC_PERMS "create", "destroy", "getattr", "setattr", "read",
> \
> "write", "associate", "unix_read", "unix_write"
> --
> 2.1.0.rc2.206.gedb03e5
>
>
> Selinux mailing list
> Selinux@xxxxxxxxxxxxx
> To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
> To get help, send an email containing "help" to
> Selinux-request@xxxxxxxxxxxxx.
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
