All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov, jmorris@namei.org,
	sds@tycho.nsa.gov
Subject: Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
Date: Fri, 29 Sep 2006 13:38:45 -0400	[thread overview]
Message-ID: <451D5A25.9090803@hp.com> (raw)
In-Reply-To: <36282A1733C57546BE392885C0618592015CF2DE@chaos.tcs.tcs-sec.com>

Venkat Yekkirala wrote:
>>>+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
>>>+{
>>>+	u32 trans_sid;
>>>+	int err;
>>>+
>>>+	if (selinux_compat_net)
>>>+		return 1;
>>>+
>>>+	if (!skb->secmark) {
>>>+		u32 xfrm_sid;
>>>+
>>>+		selinux_skb_xfrm_sid(skb, &xfrm_sid);
>>>+
>>>+		if (xfrm_sid)
>>>+			skb->secmark = xfrm_sid;
>>>+		else if (skb->sk) {
>>>+			struct sk_security_struct *sksec = 
>>
>>skb->sk->sk_security;
>>
>>>+			skb->secmark = sksec->sid;
>>>+		}
>>>+	}
>>>+
>>>+	err = avc_has_perm(skb->secmark, nf_secid, SECCLASS_PACKET,
>>>+				PACKET__FLOW_OUT, NULL);
>>
>>While I don't see any explicit mention of it in the documentation or
>>your comments, I assume we would want a flow_out check for 
>>NetLabel here
>>as well?
>  
> I don't believe we do. By this time, the packet is or should already be
> carrying the CIPSO/NetLabel option which should already be the right one
> (derived from the socket or flow as appropriate), but you would want to
> audit the code to make sure. IOW, the label option in the IP header should
> already be reflecting the secmark on the skb. But again, you may want to
> audit the code to make sure.

In the case above I am concerned about the situation where the
skb->secmark == 0 and there is a IPv4 option (i.e. it is NetLabel
labeled) on the packet.  It would seem that the right/consistent thing
to do would be to adjust the secmark accordingly, similar to what we
would do on the flow_in case, yes?

>>>+static int selinux_ip_postroute_last_compat(struct sock 
>>
>>*sk, struct sk_buff *skb,
>>
>>>+					    struct net_device *dev,
>>> 					    struct avc_audit_data *ad,
>>> 					    u16 family, char 
>>
>>*addrp, int len)
>>
>>> {
>>>@@ -3710,6 +3777,9 @@ static int selinux_ip_postroute_last_com
>>> 	struct inode *inode;
>>> 	struct inode_security_struct *isec;
>>> 
>>>+	if (!sk)
>>>+		goto out;
>>>+
>>> 	sock = sk->sk_socket;
>>> 	if (!sock)
>>> 		goto out;
>>>@@ -3768,7 +3838,11 @@ static int selinux_ip_postroute_last_com
>>> 
>>> 		err = avc_has_perm(isec->sid, port_sid, isec->sclass,
>>> 				   send_perm, ad);
>>>+		if (err)
>>>+			goto out;
>>> 	}
>>>+
>>>+	err = selinux_xfrm_postroute_last(isec->sid, skb, ad);
>>> out:
>>> 	return err;
>>> }
>>>@@ -3782,17 +3856,9 @@ static unsigned int selinux_ip_postroute
>>> {
>>> 	char *addrp;
>>> 	int len, err = 0;
>>>-	struct sock *sk;
>>> 	struct sk_buff *skb = *pskb;
>>> 	struct avc_audit_data ad;
>>> 	struct net_device *dev = (struct net_device *)out;
>>>-	struct sk_security_struct *sksec;
>>>-
>>>-	sk = skb->sk;
>>>-	if (!sk)
>>>-		goto out;
>>>-
>>>-	sksec = sk->sk_security;
>>> 
>>> 	AVC_AUDIT_DATA_INIT(&ad, NET);
>>> 	ad.u.net.netif = dev->name;
>>>@@ -3803,16 +3869,25 @@ static unsigned int selinux_ip_postroute
>>> 		goto out;
>>> 
>>> 	if (selinux_compat_net)
>>>-		err = selinux_ip_postroute_last_compat(sk, dev, &ad,
>>>+		err = selinux_ip_postroute_last_compat(skb->sk, 
>>
>>skb, dev, &ad,
>>
>>> 						       family, 
>>
>>addrp, len);
>>
>>>-	else
>>>-		err = avc_has_perm(sksec->sid, skb->secmark, 
>>
>>SECCLASS_PACKET,
>>
>>>-				   PACKET__SEND, &ad);
>>>+	else {
>>>+		if (!skb->secmark) {
>>>+			u32 xfrm_sid;
>>> 
>>>-	if (err)
>>>-		goto out;
>>>+			selinux_skb_xfrm_sid(skb, &xfrm_sid);
>>> 
>>>-	err = selinux_xfrm_postroute_last(sksec->sid, skb, &ad);
>>>+			if (xfrm_sid)
>>>+				skb->secmark = xfrm_sid;
>>>+			else if (skb->sk) {
>>>+				struct sk_security_struct *sksec =
>>>+						skb->sk->sk_security;
>>>+				skb->secmark = sksec->sid;
>>>+			}
>>>+		}
>>>+		err = avc_has_perm(skb->secmark, SECINITSID_UNLABELED,
>>>+				   SECCLASS_PACKET, 
>>
>>PACKET__FLOW_OUT, &ad);
>>
>>>+	}
>>
>>This looks nearly identical to selinux_skb_flow_out() as implemented
>>above, the only real differences being two of the args to the
>>avc_has_perm() call.  Any reason you don't abstract out the 
>>common parts
>>to a separate function?
> 
> May be in the future.
> 
>>Also, the same comment/question about NetLabel support in
>>selinux_skb_flow_out() applies here as well I suspect.
> 
> My comments earlier should apply here as well. 

Mine too :)

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

WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov, jmorris@namei.org,
	sds@tycho.nsa.gov
Subject: Re: [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux
Date: Fri, 29 Sep 2006 13:38:45 -0400	[thread overview]
Message-ID: <451D5A25.9090803@hp.com> (raw)
In-Reply-To: <36282A1733C57546BE392885C0618592015CF2DE@chaos.tcs.tcs-sec.com>

Venkat Yekkirala wrote:
>>>+static int selinux_skb_flow_out(struct sk_buff *skb, u32 nf_secid)
>>>+{
>>>+	u32 trans_sid;
>>>+	int err;
>>>+
>>>+	if (selinux_compat_net)
>>>+		return 1;
>>>+
>>>+	if (!skb->secmark) {
>>>+		u32 xfrm_sid;
>>>+
>>>+		selinux_skb_xfrm_sid(skb, &xfrm_sid);
>>>+
>>>+		if (xfrm_sid)
>>>+			skb->secmark = xfrm_sid;
>>>+		else if (skb->sk) {
>>>+			struct sk_security_struct *sksec = 
>>
>>skb->sk->sk_security;
>>
>>>+			skb->secmark = sksec->sid;
>>>+		}
>>>+	}
>>>+
>>>+	err = avc_has_perm(skb->secmark, nf_secid, SECCLASS_PACKET,
>>>+				PACKET__FLOW_OUT, NULL);
>>
>>While I don't see any explicit mention of it in the documentation or
>>your comments, I assume we would want a flow_out check for 
>>NetLabel here
>>as well?
>  
> I don't believe we do. By this time, the packet is or should already be
> carrying the CIPSO/NetLabel option which should already be the right one
> (derived from the socket or flow as appropriate), but you would want to
> audit the code to make sure. IOW, the label option in the IP header should
> already be reflecting the secmark on the skb. But again, you may want to
> audit the code to make sure.

In the case above I am concerned about the situation where the
skb->secmark == 0 and there is a IPv4 option (i.e. it is NetLabel
labeled) on the packet.  It would seem that the right/consistent thing
to do would be to adjust the secmark accordingly, similar to what we
would do on the flow_in case, yes?

>>>+static int selinux_ip_postroute_last_compat(struct sock 
>>
>>*sk, struct sk_buff *skb,
>>
>>>+					    struct net_device *dev,
>>> 					    struct avc_audit_data *ad,
>>> 					    u16 family, char 
>>
>>*addrp, int len)
>>
>>> {
>>>@@ -3710,6 +3777,9 @@ static int selinux_ip_postroute_last_com
>>> 	struct inode *inode;
>>> 	struct inode_security_struct *isec;
>>> 
>>>+	if (!sk)
>>>+		goto out;
>>>+
>>> 	sock = sk->sk_socket;
>>> 	if (!sock)
>>> 		goto out;
>>>@@ -3768,7 +3838,11 @@ static int selinux_ip_postroute_last_com
>>> 
>>> 		err = avc_has_perm(isec->sid, port_sid, isec->sclass,
>>> 				   send_perm, ad);
>>>+		if (err)
>>>+			goto out;
>>> 	}
>>>+
>>>+	err = selinux_xfrm_postroute_last(isec->sid, skb, ad);
>>> out:
>>> 	return err;
>>> }
>>>@@ -3782,17 +3856,9 @@ static unsigned int selinux_ip_postroute
>>> {
>>> 	char *addrp;
>>> 	int len, err = 0;
>>>-	struct sock *sk;
>>> 	struct sk_buff *skb = *pskb;
>>> 	struct avc_audit_data ad;
>>> 	struct net_device *dev = (struct net_device *)out;
>>>-	struct sk_security_struct *sksec;
>>>-
>>>-	sk = skb->sk;
>>>-	if (!sk)
>>>-		goto out;
>>>-
>>>-	sksec = sk->sk_security;
>>> 
>>> 	AVC_AUDIT_DATA_INIT(&ad, NET);
>>> 	ad.u.net.netif = dev->name;
>>>@@ -3803,16 +3869,25 @@ static unsigned int selinux_ip_postroute
>>> 		goto out;
>>> 
>>> 	if (selinux_compat_net)
>>>-		err = selinux_ip_postroute_last_compat(sk, dev, &ad,
>>>+		err = selinux_ip_postroute_last_compat(skb->sk, 
>>
>>skb, dev, &ad,
>>
>>> 						       family, 
>>
>>addrp, len);
>>
>>>-	else
>>>-		err = avc_has_perm(sksec->sid, skb->secmark, 
>>
>>SECCLASS_PACKET,
>>
>>>-				   PACKET__SEND, &ad);
>>>+	else {
>>>+		if (!skb->secmark) {
>>>+			u32 xfrm_sid;
>>> 
>>>-	if (err)
>>>-		goto out;
>>>+			selinux_skb_xfrm_sid(skb, &xfrm_sid);
>>> 
>>>-	err = selinux_xfrm_postroute_last(sksec->sid, skb, &ad);
>>>+			if (xfrm_sid)
>>>+				skb->secmark = xfrm_sid;
>>>+			else if (skb->sk) {
>>>+				struct sk_security_struct *sksec =
>>>+						skb->sk->sk_security;
>>>+				skb->secmark = sksec->sid;
>>>+			}
>>>+		}
>>>+		err = avc_has_perm(skb->secmark, SECINITSID_UNLABELED,
>>>+				   SECCLASS_PACKET, 
>>
>>PACKET__FLOW_OUT, &ad);
>>
>>>+	}
>>
>>This looks nearly identical to selinux_skb_flow_out() as implemented
>>above, the only real differences being two of the args to the
>>avc_has_perm() call.  Any reason you don't abstract out the 
>>common parts
>>to a separate function?
> 
> May be in the future.
> 
>>Also, the same comment/question about NetLabel support in
>>selinux_skb_flow_out() applies here as well I suspect.
> 
> My comments earlier should apply here as well. 

Mine too :)

-- 
paul moore
linux security @ hp

  reply	other threads:[~2006-09-29 17:38 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-29 17:27 [PATCH 7/7] secid reconciliation-v03: Enforcement for SELinux Venkat Yekkirala
2006-09-29 17:27 ` Venkat Yekkirala
2006-09-29 17:38 ` Paul Moore [this message]
2006-09-29 17:38   ` Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2006-10-01 21:30 Venkat Yekkirala
2006-10-01 21:30 ` Venkat Yekkirala
2006-09-29 22:10 Venkat Yekkirala
2006-09-29 22:10 ` Venkat Yekkirala
2006-09-29 21:54 Venkat Yekkirala
2006-09-29 21:54 ` Venkat Yekkirala
2006-09-29 18:50 Venkat Yekkirala
2006-09-29 18:50 ` Venkat Yekkirala
2006-09-29 19:13 ` Paul Moore
2006-09-29 19:13   ` Paul Moore
2006-09-29 16:27 Venkat Yekkirala
2006-09-29 16:27 ` Venkat Yekkirala
2006-09-29 16:31 ` Paul Moore
2006-09-29 16:31   ` Paul Moore
2006-09-29 16:50   ` James Morris
2006-09-29 16:50     ` James Morris
2006-09-29 17:32     ` James Morris
2006-09-29 17:32       ` James Morris
2006-09-29 17:50       ` Paul Moore
2006-09-29 17:50         ` Paul Moore
2006-09-29 17:43     ` Paul Moore
2006-09-29 17:43       ` Paul Moore
2006-09-29 18:41       ` James Morris
2006-09-29 18:41         ` James Morris
2006-09-29 19:06         ` Paul Moore
2006-09-29 19:06           ` Paul Moore
2006-09-29 19:33           ` James Morris
2006-09-29 19:33             ` James Morris
2006-09-29 19:51             ` Paul Moore
2006-09-29 19:51               ` Paul Moore
2006-09-29 20:04               ` James Morris
2006-09-29 20:04                 ` James Morris
2006-09-29 20:09                 ` Paul Moore
2006-09-29 20:09                   ` Paul Moore
2006-09-29 16:22 Venkat Yekkirala
2006-09-29 16:22 ` Venkat Yekkirala
2006-09-29 16:17 Venkat Yekkirala
2006-09-29 16:17 ` Venkat Yekkirala
2006-09-29 16:09 Venkat Yekkirala
2006-09-29 16:09 ` Venkat Yekkirala
2006-09-29 16:13 ` Paul Moore
2006-09-29 16:13   ` Paul Moore
2006-09-29  2:33 Venkat Yekkirala
2006-09-29  2:33 ` Venkat Yekkirala
2006-09-29  3:52 ` Joshua Brindle
2006-09-29  3:52   ` Joshua Brindle
2006-09-29 12:59   ` Stephen Smalley
2006-09-29 12:59     ` Stephen Smalley
2006-09-29 14:00     ` Joshua Brindle
2006-09-29 14:00       ` Joshua Brindle
2006-09-29 14:28       ` Stephen Smalley
2006-09-29 14:28         ` Stephen Smalley
2006-09-29 14:33         ` James Morris
2006-09-29 14:33           ` James Morris
2006-09-29 14:39           ` Stephen Smalley
2006-09-29 14:39             ` Stephen Smalley
2006-09-29 16:06             ` Paul Moore
2006-09-29 16:06               ` Paul Moore
2006-09-29 16:10               ` James Morris
2006-09-29 16:10                 ` James Morris
2006-09-29 16:15                 ` Paul Moore
2006-09-29 16:15                   ` Paul Moore
2006-09-29 16:39 ` Paul Moore
2006-09-29 16:39   ` 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=451D5A25.9090803@hp.com \
    --to=paul.moore@hp.com \
    --cc=jmorris@namei.org \
    --cc=netdev@vger.kernel.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.