netdev - Re: [RFC PATCH v2 2/2] selinux: Support for the new TUN LSM hooks

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 12 Aug 2009 18:55:23 -0400
From:	Paul Moore <paul.moore@...com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
	selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH v2 2/2] selinux: Support for the new TUN LSM hooks

On Wednesday 12 August 2009 06:14:40 pm Serge E. Hallyn wrote:
> Quoting Paul Moore (paul.moore@...com):
> > +static int selinux_tun_dev_attach(struct sock *sk)
> > +{
> > +	struct sk_security_struct *sksec = sk->sk_security;
> > +	u32 sid = current_sid();
> > +	int err;
> > +
> > +	err = avc_has_perm(sid, sksec->sid, SECCLASS_TUN_SOCKET,
> > +			   TUN_SOCKET__RELABELFROM, NULL);
> > +	if (err)
> > +		return err;
> > +	err = avc_has_perm(sid, sid, SECCLASS_RAWIP_SOCKET,
>
> Was RAWIP on purpose here?

Nope, a mistake on my part that I hadn't caught yet.  Thanks.

> > +			   TUN_SOCKET__RELABELTO, NULL);
> > +	if (err)
> > +		return err;
> > +
> > +	sksec->sid = sid;
> > +
> > +	return 0;
> > +}
>
> IIUC it is possible for multiple processes to attach to the same
> tun device.  Will it get confusing/incorrect to have each attach
> potentially (if tasks have different sids) relabel?

I may be reading the code wrong, but in drivers/net/tun.c:tun_attach() the 
code checks to see if the TUN device is already in use and if it is then the 
attach fails with -EBUSY (check where the tun_device->tfile is examined).  I 
believe this should ensure that only one process at a time has access to the 
TUN device so we shouldn't have to worry about a TUN socket getting relabeled 
while it is currently in use.  As far as persistent TUN devices getting 
relabeled when a new process attaches to them, that is what we are trying to 
accomplish here so that the network traffic being sent via the TUN device is 
labeled according to the currently attached process; this is consistent with 
how SELinux currently labels locally generated outbound traffic - outbound 
packets inherit their security label from the sending process via the 
originating socket/sock.

-- 
paul moore
linux @ hp

--
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