All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Cc: selinux@tycho.nsa.gov, jmorris@namei.org, sds@tycho.nsa.gov
Subject: Re: Networking Patch (outline)
Date: Wed, 5 Sep 2007 18:27:11 -0400	[thread overview]
Message-ID: <200709051827.11946.paul.moore@hp.com> (raw)
In-Reply-To: <46D898D3.7020400@trustedcs.com>

Some more thoughts on the patch as I keep looking at it and thinking ...

On Friday, August 31 2007 6:40:19 pm Venkat Yekkirala wrote:
> Specifically, the following are the primary areas that
> have not been addressed here:
>
> 4. Currently this patch modifies xfrm_policy_check()
>    to also perform the flow_in checks. This is awkward and
>    a separate call into LSM right after the xfrm_policy_check
>    invocations would be cleaner.

It would be great if we could do something with a netfilter PRE_ROUTING hook 
similar to how we handle outbound packets with a POST_ROUTING hook.  I just 
spent some time looking at the XFRM input code path and it looks like AH/ESP 
transport packets make two trips through the PRE_ROUTING hook, once before 
the transformation (skb->sp == NULL) and once afterwards (skb->sp != NULL).  
Tunnel mode transforms should be handled because they run back through the 
stack starting with the initial IP receive routine so they will be caught the 
second time around.  However, I haven't spent as much time looking at either 
the labeled IPsec or flow control bits as you so I might be overlooking some 
important things.  Does this sound like it might work from a labeled IPsec 
point of view?

The only real gotcha I can see to this approach is CIPSO, or any other IP 
options based labeling protocol, because the ip_rcv_options() routine is not 
called until after the PRE_ROUTING hooks have been called.  We need this as 
the ip_options_compile() routine is the one which parses/validates the IP 
options.  If this is the only problem we can probably work around it by 
calling it (or ip_options_compile() directly) in our hook and making it 
smarter so that it doesn't run a second time if IPCB(skb)->opt is not NULL.

> --- linux-2.6.orig/security/selinux/hooks.c	2007-08-30 09:18:01.000000000
> -0500 +++ linux-2.6/security/selinux/hooks.c	2007-08-31 15:35:54.000000000
> -0500 @@ -3146,6 +3146,11 @@ static void selinux_skb_extlbl_sid(struc
>  	u32 xfrm_sid;
>  	u32 nlbl_sid;
>
> +	if (skb->secid) {
> +		*sid = skb->secid;
> +		return;
> +	}
> +
>  	selinux_skb_xfrm_sid(skb, &xfrm_sid);
>  	if (selinux_netlbl_skbuff_getsid(skb,
>  					 (xfrm_sid == SECSID_NULL ?
> @@ -3629,9 +3634,28 @@ static int selinux_socket_sock_rcv_skb(s
>  	if (selinux_compat_net)
>  		err = selinux_sock_rcv_skb_compat(sk, skb, &ad, family,
>  						  addrp, len);
> -	else
> +	else {
> +		u32 recv_perm;
> +
>  		err = avc_has_perm(sksec->sid, skb->secmark, SECCLASS_PACKET,
>  				   PACKET__RECV, &ad);
> +		if (err)
> +			goto out;
> +
> +		switch (sksec->sclass) {
> +		case SECCLASS_UDP_SOCKET:
> +			recv_perm = UDP_SOCKET__RECVFROM;
> +			break;
> +		case SECCLASS_TCP_SOCKET:
> +			recv_perm = TCP_SOCKET__RECVFROM;
> +			break;
> +		default:
> +			recv_perm = RAWIP_SOCKET__RECVFROM;
> +		}
> +
> +		err = avc_has_perm(sksec->sid, skb->secid, sksec->sclass,
> +				   recv_perm, &ad);
> +	}
>  	if (err)
>  		goto out;

One thing I've been wondering about lately - is the distinction between 
different types of sockets useful?  From discussions which Chris, the policy 
guys seem not to care, which makes me think we are needlessly making life 
difficult for ourselves.  However, if other third-parties see a need for the 
distinction ...

> @@ -3804,6 +3828,62 @@ static void selinux_req_classify_flow(co
>  	fl->secid = req->secid;
>  }
>
> +void selinux_igmp_classify_skb(struct sk_buff *skb)
> +{
> +	skb->secid = SECINITSID_IGMP_PACKET;
> +}
> +
> +static int selinux_skb_flow_in(struct sk_buff *skb, unsigned short family)
> +{
> +	u32 if_sid;
> +	int err;
> +	struct avc_audit_data ad;
> +	char *addrp;
> +	int len;
> +
> +	if (selinux_compat_net)
> +		return 1;
> +
> +	if (!skb->dev) {
> +		err = -EACCES;
> +		goto out;
> +	}
> +
> +	AVC_AUDIT_DATA_INIT(&ad, NET);
> +	ad.u.net.netif = skb->dev->name;
> +	ad.u.net.family = family;
> +	err = selinux_parse_skb(skb, &ad, &addrp, &len, 1, NULL);
> +	if (err)
> +		goto out;
> +
> +	if (skb->dev != &loopback_dev) { /* Non-localhost packet */
> +		err = selinux_xfrm_decode_session(skb, &skb->secid, 0);
> +		BUG_ON(err);
> +		/* TODO: Retrieve and check any NetLabel for agreement with
> +		   any Xfrm; also retrieve fallback if necessary */
> +	}
> +#ifdef TODO
> +	else /* localhost packet */
> +		/* TODO: Retrieve special IP Option set for localhost traffic */
> +
> +	err = avc_has_perm(skb->secid, NODE /* TODO */, SECCLASS_PACKET,
> PACKET__FLOW_IN, &ad); +	if (err)
> +		goto out;
> +#endif
> +
> +	/* See if skb can flow in thru the interface */
> +	err = sel_netif_sids(skb->dev, &if_sid, NULL);
> +	if (err)
> +		goto out;
> +
> +	err = avc_has_perm(skb->secid, if_sid,
> +					SECCLASS_NETIF,
> +					NETIF__FLOW_IN, &ad);

I assume this is where the host/node check would go?  Would it make sense to 
create a combined interface/network label and check so that we could do one 
lookup and one access check instead of two?

Same applies to postroute().

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2007-09-05 22:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 22:40 Networking Patch (outline) Venkat Yekkirala
2007-08-31 23:04 ` Paul Moore
2007-09-05 22:27 ` Paul Moore [this message]
2007-09-06 16:08   ` Venkatesh Yekkirala
2007-09-06 17:34     ` Paul Moore
2007-09-11 16:37       ` Venkatesh Yekkirala
2007-09-11 19:31         ` Paul Moore
2007-09-12 17:08           ` Venkatesh Yekkirala
2007-09-12 18:52             ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709051827.11946.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=jmorris@namei.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=vyekkirala@TrustedCS.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.