RE: Labeled Networking For LSPP: Where we are and where we need t o go (quickly)

RE: Labeled Networking For LSPP: Where we are and where we need t o go (quickly)

[Venkat Yekkirala]

Paul Moore wrote:
> Eric Paris wrote:
> > Last night I built a new test kernel for labeled networking in RHEL5
> > kernels.  That kernel can be found at 
> > 
> > http://people.redhat.com/sgrubb/files/lspp
> > 
> > and you want the lspp kernel 51.
> > 
<snip>
> > Patch3: find and fix current issues with unlabeled_t 
> packets that can't
> > be explained (Paul Moore and Venkat)
> 
> I'm working on this but it's taking time getting all the 
> right policy bits
> sorted so I can differentiate between SECINITSID_UNLABELED 
> and SECINITSID_NETMSG
> as they will both show up as "unlabeled_t" in all the 
> released policies (at
> least I think so).
> 
> Venkat, if you have a policy rpm/clean-patch/tarball 
> something it would be a
> help if you could post that or send it to me (I saw your 
> earlier postings, but
> only the constraints were really in patch form).  Or if you 
> could verify the
> lspp.51 kernel w/o the NetLabel/secid patch (turn off patch 
> 25008, if you want I
> can send you a diff to the spec file - it's only two lines).  
> So far I have not
> seen any differences between the stock lspp.51 kernel and the 
> lspp.51 kernel
> without the NetLabel/secid patch.

As for the policy, I don't have anything more than what I posted
earlier. To distinguish between the SECINITSID_NULL and NETMSG,
see the policy patch I posted, sepcifically, policy/domains/kernel/kernel.te
where you will see that NETMSG is being set to network_t. You should
be able to apply at least that one bit of patch.

ALso, are you seeing the following denials without NetLabel/secid?

[Pasted from Jashua's email]

avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon"
scontext=system_u:object_r:unlabeled_t:s0
tcontext=system_u:system_r:avahi_t:s0 tclass=packet

don't understand this one at all, source should be network_t (i thought)
and target should be a packet object (and there aren't any). Why is it
getting the domain context?

avc:  denied  { recv } for  pid=1815 comm="avahi-daemon" src=5353 dest=5353
netif=eth0 scontext=system_u:system_r:avahi_t:s0
tcontext=system_u:system_r:avahi_t:s0 tclass=packet

So the source here seems correct but the target is avahi_t again..

> 
> > There also is some question from Joshua Brindle if the 
> object classes
> > are correct for a number of things.  These changes also 
> will need to be
> > done quickly.  I'm going to call this Patch4.
> > 
> > Patch4: verify/fix the object class for all netlabel hooks. 
>  (Hopefully
> > Venkat will be able to take the lead on this)
> 
> Just to clarify, these aren't netlabel specific 
> hooks/changes, these are secid
> hooks/changes.  Otherwise, I agree, Venkat has the best 
> understanding of this
> work so I believe he should "drive" - I'll do whatever I can 
> to support this work.
> 
> -- 
> 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.

Re: Labeled Networking For LSPP: Where we are and where we need t o go (quickly)

[Paul Moore]

Venkat Yekkirala wrote:
> Paul Moore wrote:
> 
>>Eric Paris wrote:
>>
>>>Last night I built a new test kernel for labeled networking in RHEL5
>>>kernels.  That kernel can be found at 
>>>
>>>http://people.redhat.com/sgrubb/files/lspp
>>>
>>>and you want the lspp kernel 51.
>>>
> 
> <snip>
> 
>>>Patch3: find and fix current issues with unlabeled_t 
>>
>>packets that can't
>>
>>>be explained (Paul Moore and Venkat)
>>
>>I'm working on this but it's taking time getting all the 
>>right policy bits
>>sorted so I can differentiate between SECINITSID_UNLABELED 
>>and SECINITSID_NETMSG
>>as they will both show up as "unlabeled_t" in all the 
>>released policies (at
>>least I think so).
>>
>>Venkat, if you have a policy rpm/clean-patch/tarball 
>>something it would be a
>>help if you could post that or send it to me (I saw your 
>>earlier postings, but
>>only the constraints were really in patch form).  Or if you 
>>could verify the
>>lspp.51 kernel w/o the NetLabel/secid patch (turn off patch 
>>25008, if you want I
>>can send you a diff to the spec file - it's only two lines).  
>>So far I have not
>>seen any differences between the stock lspp.51 kernel and the 
>>lspp.51 kernel
>>without the NetLabel/secid patch.
>  
> As for the policy, I don't have anything more than what I posted
> earlier. To distinguish between the SECINITSID_NULL and NETMSG,
> see the policy patch I posted, sepcifically, policy/domains/kernel/kernel.te
> where you will see that NETMSG is being set to network_t. You should
> be able to apply at least that one bit of patch.

Yes, I was hoping to have something I could just rpm/yum onto the machine so
there would be no issues about specific version I was using.  However, if it's
not possibile, it's not possibile.

One thing that does cause me to wonder is that Joshua said he was using the
targeted policy from Rawhide, which doesn't have SECINITSID_NETMSG assigned to
network_t I don't believe ...

> ALso, are you seeing the following denials without NetLabel/secid?
> 
> [Pasted from Jashua's email]
> 
> avc:  denied  { flow_in } for  pid=1815 comm="avahi-daemon"
> scontext=system_u:object_r:unlabeled_t:s0
> tcontext=system_u:system_r:avahi_t:s0 tclass=packet

[NOTE: this is with the 2.3.7-2 mls policy - I know, it's really old]

Here is what I have seen using lspp.51:

type=AVC msg=audit(1160150058.918:61): avc:  denied  { flow_in } for  pid=2296
comm="avahi-daemon" scontext=system_u:object_r:unlabeled_t:s15:c0.c255
tcontext=system_u:object_r:unlabeled_t:s15:c0.c255 tclass=packet

type=AVC msg=audit(1160150058.918:61): avc:  denied  { flow_out } for  pid=2296
comm="avahi-daemon" saddr=10.0.0.255 src=5353 daddr=224.0.0.251 dest=5353
netif=eth0 scontext=root:staff_r:staff_t:s0-s15:c0.c255
tcontext=system_u:object_r:unlabeled_t:s15:c0.c255 tclass=packet

Here is what I have seen using lspp.51 without the NetLabel/secid patch:

type=AVC msg=audit(1160149828.291:105): avc:  denied  { flow_in } for  pid=2429
comm="avahi-daemon" scontext=system_u:object_r:unlabeled_t:s15:c0.c255
tcontext=system_u:object_r:unlabeled_t:s15:c0.c255 tclass=packet

type=AVC msg=audit(1160149828.291:105): avc:  denied  { flow_out } for  pid=2429
comm="avahi-daemon" saddr=10.0.0.255 src=5353 daddr=224.0.0.251 dest=5353
netif=eth0 scontext=root:staff_r:staff_t:s0-s15:c0.c255
tcontext=system_u:object_r:unlabeled_t:s15:c0.c255 tclass=packet

So no real visible difference in the contexts, I'm going to keep working on this
but if you haven't already started looking into this yourself it might be a good
idea considering the time crunch.  One tidbit worth noting, I never saw any
"recv" denials; I'm not sure if the daemon just didn't receive any packets or if
 the permission was already allowed ...

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

RE: Labeled Networking For LSPP: Where we are and where we need t o go (quickly)

[Venkat Yekkirala]

> This is great, we are getting there.  But, we still need at least 3-4
> more patches before tomorrow!!
> 
> Patch1: finish the error propagation backport for the ipsec 
> leak (Being
> completed by Eric Paris)
> Patch2: audit ipsec config changes (Being completed by Joy Latten)
> Patch3: find and fix current issues with unlabeled_t packets 
> that can't
> be explained (Paul Moore and Venkat)
I am currently investigating this and hope to have a patch by Monday.

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