> >>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's unfortunate that you cut out the code in your reply.
It's even more unfortunate that you should say this. The proper
thing
> It seems more of a pain to actually
> prevent their use at the same time and/or explain
> strange/unnatural
> behavior.
> >>>
> >>>Agreed, the solution that we agreed upon is much easier to
> implement and
> >>>explain than a lot of the alternatives.
> >>
> >>Ok, can you please expl
> Venkat,
>
> With xfrm labeling, the external packets are always going to
> be protocol
> ESP or AH, and we can't connection track the inner protocols. So,
Are you sure? This doesn't compare to what my limited testing seems
to have turned up (normal netfiltering of inner protos followed by x
On Fri, 29 Sep 2006, Paul Moore wrote:
> > ... or related packet doesn't match ...
>
> Not sure what you mean by "related packet",
A related packet with conntrack would be an FTP data packet related to a
specific FTP control session (where the conntrack is initialized, and has
a secmark saved
James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>>>... or you get no CIPSO label (e.g. ICMP from intermediate router) ...
>>
>>If there is no packet label that NetLabel recognizes and NetLabel is
>>configured to allow unlabeled traffic then the NetLabel SID generated in
>>step #1 above
James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>
>
>>>Say that the SA is labeled "secret" and you have two FTP clients
>>>connecting to a server via xinetd on this SA. Each client additionally
>>>labels their packets via CIPSO as secret:c1 and secret:c2 respectively.
>>>xinetd
On Fri, 29 Sep 2006, Paul Moore wrote:
> > Say that the SA is labeled "secret" and you have two FTP clients
> > connecting to a server via xinetd on this SA. Each client additionally
> > labels their packets via CIPSO as secret:c1 and secret:c2 respectively.
> > xinetd launches an FTP server
Venkat Yekkirala wrote:
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 th
James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>
>>James Morris wrote:
>>
>>>Ok, can you please explain it further?
>>>
>>>i.e. show me what the policy looks like, exactly what the user is trying
>>>to achieve, and explain what happens to each packet exactly in terms of
>>>labeling
> >>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 s
On Fri, 29 Sep 2006, Paul Moore wrote:
> James Morris wrote:
> > Ok, can you please explain it further?
> >
> > i.e. show me what the policy looks like, exactly what the user is trying
> > to achieve, and explain what happens to each packet exactly in terms of
> > labeling on the input and outp
James Morris wrote:
> On Fri, 29 Sep 2006, James Morris wrote:
>
>
>>On Fri, 29 Sep 2006, Paul Moore wrote:
>>
>>
It seems more of a pain to actually
prevent their use at the same time and/or explain strange/unnatural
behavior.
>>>
>>>Agreed, the solution that we agreed upon is much e
James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>
>>>It seems more of a pain to actually
>>>prevent their use at the same time and/or explain strange/unnatural
>>>behavior.
>>
>>Agreed, the solution that we agreed upon is much easier to implement and
>>explain than a lot of the altern
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_sk
On Fri, 29 Sep 2006, James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>
> > > It seems more of a pain to actually
> > > prevent their use at the same time and/or explain strange/unnatural
> > > behavior.
> >
> > Agreed, the solution that we agreed upon is much easier to implement and
> > +static int selinux_skb_flow_in(struct sk_buff *skb,
> unsigned short family)
> > +{
> > + u32 xfrm_sid, trans_sid;
> > + int err;
> > +
> > + if (selinux_compat_net)
> > + return 1;
> > +
> > + /* xfrm/cipso inapplicable for loopback traffic */
> > + if (skb->dev == &loopb
On Fri, 29 Sep 2006, Paul Moore wrote:
> > It seems more of a pain to actually
> > prevent their use at the same time and/or explain strange/unnatural
> > behavior.
>
> Agreed, the solution that we agreed upon is much easier to implement and
> explain than a lot of the alternatives.
Ok, can you
Venkat Yekkirala wrote:
> This defines SELinux enforcement of the 2 new LSM hooks as well
> as related changes elsewhere in the SELinux code.
As soon as I hit send on this mail I'll start working on the related
patch to provide the missing NetLabel support.
Additional comments are below.
> Signe
Venkat Yekkirala wrote:
>>I tend to agree, I just can't see it being all that useful in the real
>>world. However, each time it comes up (including the conference call
>>earlier this week) it seems that people would prefer to use
>>both at the
>>same time.
>
> A matter of providing options to u
> That's fine by me, I just wanted to make sure something like
> that would
> be acceptable. So, in summary, we would do the normal flow_in checks
> for both IPsec and NetLabel and then set the secmark using the IPsec
> label as the "base sid" for the NetLabel's generated SID?
That's correct (in
> I tend to agree, I just can't see it being all that useful in the real
> world. However, each time it comes up (including the conference call
> earlier this week) it seems that people would prefer to use
> both at the
> same time.
A matter of providing options to users. It seems more of a pain
> > Unless I'm confusing something, there still may be a need
> for transitions
> > if we want to support both IPsec and NetLabel labeling on the same
> > connection.
>
> I'd prefer not to support this, as it's too complicated,
Actually, from my vantage point, it actually seems "natural".
> and
James Morris wrote:
> On Fri, 29 Sep 2006, Paul Moore wrote:
>
>
>>Unless I'm confusing something, there still may be a need for transitions
>>if we want to support both IPsec and NetLabel labeling on the same
>>connection.
>
> I'd prefer not to support this, as it's too complicated, and CIPSO i
Venkat Yekkirala wrote:
>>>Fine with me, unless Venkat has an immediate use case for such
>>>transitions in the flow_in case (but I think this is mostly
>>
>>my fault for
>>
>>>suggesting transitions a while ago).
>
> I don't have a use case currently.
>
>>Unless I'm confusing something, there s
> > Fine with me, unless Venkat has an immediate use case for such
> > transitions in the flow_in case (but I think this is mostly
> my fault for
> > suggesting transitions a while ago).
I don't have a use case currently.
>
> Unless I'm confusing something, there still may be a need for
> tran
On Fri, 29 Sep 2006, Paul Moore wrote:
> Unless I'm confusing something, there still may be a need for transitions
> if we want to support both IPsec and NetLabel labeling on the same
> connection.
I'd prefer not to support this, as it's too complicated, and CIPSO is a
legacy protocol.
Normal I
Stephen Smalley wrote:
> On Fri, 2006-09-29 at 10:33 -0400, James Morris wrote:
>
>>On Fri, 29 Sep 2006, Stephen Smalley wrote:
>>
>>
>>>However, since the transition was removed in the flow_out case, it would
>>>be logical to remove it from the flow_in case as well, and that would
>>>have the sid
On Fri, 2006-09-29 at 10:33 -0400, James Morris wrote:
> On Fri, 29 Sep 2006, Stephen Smalley wrote:
>
> > However, since the transition was removed in the flow_out case, it would
> > be logical to remove it from the flow_in case as well, and that would
> > have the side benefit of less overhead.
On Fri, 29 Sep 2006, Stephen Smalley wrote:
> However, since the transition was removed in the flow_out case, it would
> be logical to remove it from the flow_in case as well, and that would
> have the side benefit of less overhead.
How about adding secmark transitions later, if needed, perhaps w
On Fri, 2006-09-29 at 10:00 -0400, Joshua Brindle wrote:
> On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
> > On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
> > > Venkat Yekkirala wrote:
> > > >
> > > > +
> > > > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACK
On Fri, 2006-09-29 at 08:59 -0400, Stephen Smalley wrote:
> On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
> > Venkat Yekkirala wrote:
> > >
> > > +
> > > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > > + PACKET__FLOW_IN, NULL);
> > > +
On Thu, 2006-09-28 at 23:52 -0400, Joshua Brindle wrote:
> Venkat Yekkirala wrote:
> >
> > +
> > + err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
> > + PACKET__FLOW_IN, NULL);
> > + if (err)
> > + goto out;
> > +
> > + if (xfrm_sid) {
Venkat Yekkirala wrote:
+
+ err = avc_has_perm(xfrm_sid, skb->secmark, SECCLASS_PACKET,
+ PACKET__FLOW_IN, NULL);
+ if (err)
+ goto out;
+
+ if (xfrm_sid) {
+ err = security_transition_sid(xfrm_sid, skb->secmark,
33 matches
Mail list logo
