netdev - Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 5 Aug 2009 09:03:12 -0400
From:	Eric Paris <netdev@...isplace.org>
To:	Paul Moore <paul.moore@...com>
Cc:	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH v1 1/2] lsm: Add hooks to the TUN driver

On Tue, Aug 4, 2009 at 5:21 PM, Paul Moore<paul.moore@...com> wrote:
> The TUN driver lacks any LSM hooks which makes it difficult for LSM modules,
> such as SELinux, to enforce access controls on network traffic generated by
> TUN users; this is particularly problematic for virtualization apps such as
> QEMU and KVM.  This patch adds three new LSM hooks designed to control the
> creation and attachment of TUN devices, the hooks are:
>

> diff --git a/security/commoncap.c b/security/commoncap.c
> index 48b7e02..07125a6 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -984,3 +984,29 @@ int cap_vm_enough_memory(struct mm_struct *mm, long pages)
>                cap_sys_admin = 1;
>        return __vm_enough_memory(mm, pages, cap_sys_admin);
>  }
> +
> +/**
> + * cap_tun_dev_create - Determine if creation of a new TUN device is allowed
> + *
> + * Determine if the user is allowed to create a new TUN device, historically
> + * this has always required the CAP_NET_ADMIN permission.
> + */
> +int cap_tun_dev_create(void)
> +{
> +       if (!capable(CAP_NET_ADMIN))
> +               return -EPERM;
> +       return 0;
> +}
> +
> +/**
> + * cap_tun_dev_attach - Determine if attaching to an TUN device is allowed
> + *
> + * Determine if the user is allowed to attach to an existing persistent TUN
> + * device, historically this has always required the CAP_NET_ADMIN permission.
> + */
> +int cap_tun_dev_attach(void)
> +{
> +       if (!capable(CAP_NET_ADMIN))
> +               return -EPERM;
> +       return 0;
> +}
> diff --git a/security/security.c b/security/security.c
> index dc7674f..14ebf82 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1112,6 +1112,24 @@ void security_inet_conn_established(struct sock *sk,
>        security_ops->inet_conn_established(sk, skb);
>  }
>
> +int security_tun_dev_create(void)
> +{
> +       return security_ops->tun_dev_create();
> +}
> +EXPORT_SYMBOL(security_tun_dev_create);
> +
> +void security_tun_dev_post_create(struct sock *tun_sk)
> +{
> +       return security_ops->tun_dev_post_create(tun_sk);
> +}
> +EXPORT_SYMBOL(security_tun_dev_post_create);
> +
> +int security_tun_dev_attach(struct sock *tun_sk)
> +{
> +       return security_ops->tun_dev_attach(tun_sk);
> +}
> +EXPORT_SYMBOL(security_tun_dev_attach);
> +
>  #endif /* CONFIG_SECURITY_NETWORK */
>
>  #ifdef CONFIG_SECURITY_NETWORK_XFRM

You also must add cap_tun_dev_post_create in security/capability.c and
you need to call set_to_cap_if_null() for all 3 of these new
functions.  I believe you'll see a wonderful null pointer panic if you
tried with selinux=0.....

-Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html