RHEL5 Kernel with labeled networking

RHEL5 Kernel with labeled networking

[Eric Paris]

DO NOT USE THESE KERNELS ON A PRODUCTION SYSTEM!

If you go to http://people.redhat.com/eparis/RHEL5_labeled_networking/
you should find a set of kernels based off of the Red Hat RHEL5 source
tree.  These should include patches for 

network labeling support from Venkat
netlabel auditing
ipsec/secmark secid reconciliation
netlabel secid reconciliation

I need a very fast response from everyone involved if these kernels

A) boot
B) run without labeled networking (very very important)
C) run with labeled networking

If you run across a problem feel free to let me or the list know.  You
may also feel free to open a bug in bugzilla.redhat.com for the product
choose Red Hat Enterprise Linux Public Beta and RHEL5.  If you open a
bug for this labeled networking you can go ahead and assign it to
eparis@redhat.com so I'm sure to see it and bug the correct people.

At this time there is a known ipsec problem with these kernels.  I
haven't looked at it closely but I believe the problem is that processes
which intend to send over an ipsec tunnels but have certain avc denials
will actually cause traffic to flow unencrypted.  SO PLEASE DO NOT USE
THESE ON ANY PRODUCTION SYSTEM!!  There is work going on upstream (on
linux-netdev not either of these lists) to fix this issue in the 2.6-net
tree and when it is finished it will get brought back into RHEL5.  (I
don't think you will hit this bug with relatively modern policy but it
is there and can be a serious security flaw)

Before network labeling is completed we still need some work
implementing how we plan to audit configuration changes in ipsec
labeling decisions.  I believe we agreed today that this auditing must
be done in kernelspace since we do not have fine grained enough controls
on netlink messages to allow for all of the auditing in userspace.

DO NOT USE THESE KERNELS ON A PRODUCTION SYSTEM

-Eric


--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Eric,

I've booted your kernel on the following systems:

ia64 box running rhel5 beta 1 targeted policy
x86 box running fc6t2 mls policy

I don't have any labeled networking specifically configured.

Networking only works in permissive mode.  If I put either system
in enforcing mode, I can't ping, bring up X, or do anything.

Are there some policy changes that are needed?   Seems like by default
everything should work like it did before?

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Stephen Smalley]

On Tue, 2006-10-03 at 11:34 -0400, Linda Knippers wrote:
> Eric,
> 
> I've booted your kernel on the following systems:
> 
> ia64 box running rhel5 beta 1 targeted policy
> x86 box running fc6t2 mls policy
> 
> I don't have any labeled networking specifically configured.
> 
> Networking only works in permissive mode.  If I put either system
> in enforcing mode, I can't ping, bring up X, or do anything.
> 
> Are there some policy changes that are needed?   Seems like by default
> everything should work like it did before?

Only if you set /selinux/compat_net to 1.
Otherwise, you need modified policy to define and allow flow_in/flow_out
permissions as required, and I suspect you need more in order to deal
with the fact that we now get labeled traffic on loopback by default
(thus affecting packet send/recv as well).  Venkat, do you have a policy
patch?

-- 
Stephen Smalley
National Security Agency


--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Stephen Smalley wrote:
> On Tue, 2006-10-03 at 11:34 -0400, Linda Knippers wrote:
> 
>>Eric,
>>
>>I've booted your kernel on the following systems:
>>
>>ia64 box running rhel5 beta 1 targeted policy
>>x86 box running fc6t2 mls policy
>>
>>I don't have any labeled networking specifically configured.
>>
>>Networking only works in permissive mode.  If I put either system
>>in enforcing mode, I can't ping, bring up X, or do anything.
>>
>>Are there some policy changes that are needed?   Seems like by default
>>everything should work like it did before?
> 
> 
> Only if you set /selinux/compat_net to 1.
> Otherwise, you need modified policy to define and allow flow_in/flow_out
> permissions as required, and I suspect you need more in order to deal
> with the fact that we now get labeled traffic on loopback by default
> (thus affecting packet send/recv as well).  Venkat, do you have a policy
> patch?
> 

Ok, with /selinux/compat_net set to 1, I can go into enforcing mode
on my rhel5 beta 1 targeted system.  Its got selinux-policy-2.3.3-22.

The first time I tried the same thing on my fc6/mls system it killed
all my network sessions.  The second time I tried it my established
sessions stayed up but the mouse quit working.  This system has
selinux-policy-mls-2.3.16-6.

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Linda Knippers wrote:
> Stephen Smalley wrote:
> 
>>On Tue, 2006-10-03 at 11:34 -0400, Linda Knippers wrote:
>>
>>
>>>Eric,
>>>
>>>I've booted your kernel on the following systems:
>>>
>>>ia64 box running rhel5 beta 1 targeted policy
>>>x86 box running fc6t2 mls policy
>>>
>>>I don't have any labeled networking specifically configured.
>>>
>>>Networking only works in permissive mode.  If I put either system
>>>in enforcing mode, I can't ping, bring up X, or do anything.
>>>
>>>Are there some policy changes that are needed?   Seems like by default
>>>everything should work like it did before?
>>
>>
>>Only if you set /selinux/compat_net to 1.
>>Otherwise, you need modified policy to define and allow flow_in/flow_out
>>permissions as required, and I suspect you need more in order to deal
>>with the fact that we now get labeled traffic on loopback by default
>>(thus affecting packet send/recv as well).  Venkat, do you have a policy
>>patch?
>>
> 
> 
> Ok, with /selinux/compat_net set to 1, I can go into enforcing mode
> on my rhel5 beta 1 targeted system.  Its got selinux-policy-2.3.3-22.
> 
> The first time I tried the same thing on my fc6/mls system it killed
> all my network sessions.  The second time I tried it my established
> sessions stayed up but the mouse quit working.  This system has
> selinux-policy-mls-2.3.16-6.

The mouse problem has nothing to do with this kernel.  It stops
working in mls enforcing mode with older kernels as well.  I haven't
been running X on my mls system so I never noticed before.

-- ljk


--
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: RHEL5 Kernel with labeled networking

[Eric Paris]

On Tue, 2006-10-03 at 11:34 -0400, Linda Knippers wrote:
> Eric,
> 
> I've booted your kernel on the following systems:
> 
> ia64 box running rhel5 beta 1 targeted policy
> x86 box running fc6t2 mls policy
> 
> I don't have any labeled networking specifically configured.
> 
> Networking only works in permissive mode.  If I put either system
> in enforcing mode, I can't ping, bring up X, or do anything.
> 
> Are there some policy changes that are needed?   Seems like by default
> everything should work like it did before?
> 
> -- ljk

I think there is going to need to be a policy change that I'm actually
talking with Dan about as I type this e-mail.  I think we  need

allow $1 unlabeled_t:packet { flow_in flow_out };

to be added to policy to allow things to work as they did.  I'll post
again as soon as we have a policy that appears to let normal networking
work in enforcing.

-Eric


--
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: RHEL5 Kernel with labeled networking

[James Morris]

On Tue, 3 Oct 2006, Eric Paris wrote:

> I think there is going to need to be a policy change that I'm actually
> talking with Dan about as I type this e-mail.  I think we  need
> 
> allow $1 unlabeled_t:packet { flow_in flow_out };
> 
> to be added to policy to allow things to work as they did.  I'll post
> again as soon as we have a policy that appears to let normal networking
> work in enforcing.

We need this policy in rawhide before the kernel patches are merged 
upstream, so we can note the required policy version associated with the 
patches.  We've do not want to kill Andrew Morton's box again with this 
kind of thing.


- James
-- 
James Morris
<jmorris@namei.org>

--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

James Morris wrote:
> On Tue, 3 Oct 2006, Eric Paris wrote:
> 
> 
>>I think there is going to need to be a policy change that I'm actually
>>talking with Dan about as I type this e-mail.  I think we  need
>>
>>allow $1 unlabeled_t:packet { flow_in flow_out };
>>
>>to be added to policy to allow things to work as they did.  I'll post
>>again as soon as we have a policy that appears to let normal networking
>>work in enforcing.
> 
> 
> We need this policy in rawhide before the kernel patches are merged 
> upstream, so we can note the required policy version associated with the 
> patches.  We've do not want to kill Andrew Morton's box again with this 
> kind of thing.

Dumb question....should compat_net be "1" by default?

-- ljk

--
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: RHEL5 Kernel with labeled networking

[James Morris]

On Tue, 3 Oct 2006, Linda Knippers wrote:

> Dumb question....should compat_net be "1" by default?

Ideally, no, the new secmark controls were posted in May and everyone 
should be using them.  I only added the compat_net option to help 
with transition, and it could disappear at any time.


-- 
James Morris
<jmorris@namei.org>

--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

James Morris wrote:
> On Tue, 3 Oct 2006, Linda Knippers wrote:
> 
> 
>>Dumb question....should compat_net be "1" by default?
> 
> 
> Ideally, no, the new secmark controls were posted in May and everyone 
> should be using them.  I only added the compat_net option to help 
> with transition, and it could disappear at any time.

Just seems like we're pretty early in the transition if updating
the kernel requires a new policy to not suffer a major regression,
but then I don't really understand all the secid reconciliation stuff.

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Joshua Brindle]

James Morris wrote:
> On Tue, 3 Oct 2006, Eric Paris wrote:
>
>   
>> I think there is going to need to be a policy change that I'm actually
>> talking with Dan about as I type this e-mail.  I think we  need
>>
>> allow $1 unlabeled_t:packet { flow_in flow_out };
>>
>> to be added to policy to allow things to work as they did.  I'll post
>> again as soon as we have a policy that appears to let normal networking
>> work in enforcing.
>>     
>
> We need this policy in rawhide before the kernel patches are merged 
> upstream, so we can note the required policy version associated with the 
> patches.  We've do not want to kill Andrew Morton's box again with this 
> kind of thing.
>
>   

Using these kernels I'm getting some interesting denials. I labeled the 
spd's with system_u:object_r:ipsec_spd_t:s0 so that it would be 
discernible from any socket contexts that may appear.

First I had to add a polmatch rule for unconfined_t to ipsec_spd_t, so 
far it makes sense.

Next I need polmatch on unconfined_t to unconfined_t, I assume this is 
because the SA is going to be labeled unconfined_t, seems reasonable. 
Racoon also needed setcontext for unconfined_t unconfined_t (not sure 
what the source and target mean here)

the denial I totally don't understand is:
audit(1159877238.937:35): avc:  denied  { polmatch } for  
scontext=system_u:object_r:unlabeled_t:s0 
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association

there is no unlabeled anything, except for a non-ipsec connection which 
isn't being used, I don't understand how this would happen at all.

After all that it isn't working as expected. the SA's get set up 
correctly based on the initiators socket (I'm using semanage_t in this 
case) but the reciever SA's aren't set up with the receiving process 
socket context so I get:

Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
root:system_r:semanage_t:s0-s0:c0.c255

no matter what context the server is running in.

Further, once that SA is created all domains can use it and it retains 
the same context, if I rerun the client in unconfined_t I still get:

Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
root:system_r:semanage_t:s0-s0:c0.c255

I am running in permissive (I'd hope that wouldn't affect this but I can 
see how it could) because my policy doesn't yet have flow_in and 
flow_out permissions (any chance to get a policy patch? :) )

Am I off base here, is this the expected results?

--
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: RHEL5 Kernel with labeled networking

[Joshua Brindle]

Joshua Brindle wrote:
> James Morris wrote:
>> On Tue, 3 Oct 2006, Eric Paris wrote:
>>
>>  
>>> I think there is going to need to be a policy change that I'm actually
>>> talking with Dan about as I type this e-mail.  I think we  need
>>>
>>> allow $1 unlabeled_t:packet { flow_in flow_out };
>>>
>>> to be added to policy to allow things to work as they did.  I'll post
>>> again as soon as we have a policy that appears to let normal networking
>>> work in enforcing.
>>>     
>>
>> We need this policy in rawhide before the kernel patches are merged 
>> upstream, so we can note the required policy version associated with 
>> the patches.  We've do not want to kill Andrew Morton's box again 
>> with this kind of thing.
>>
>>   
>
> Using these kernels I'm getting some interesting denials. I labeled 
> the spd's with system_u:object_r:ipsec_spd_t:s0 so that it would be 
> discernible from any socket contexts that may appear.
>
> First I had to add a polmatch rule for unconfined_t to ipsec_spd_t, so 
> far it makes sense.
>
> Next I need polmatch on unconfined_t to unconfined_t, I assume this is 
> because the SA is going to be labeled unconfined_t, seems reasonable. 
> Racoon also needed setcontext for unconfined_t unconfined_t (not sure 
> what the source and target mean here)
>
> the denial I totally don't understand is:
> audit(1159877238.937:35): avc:  denied  { polmatch } for  
> scontext=system_u:object_r:unlabeled_t:s0 
> tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=association
>
> there is no unlabeled anything, except for a non-ipsec connection 
> which isn't being used, I don't understand how this would happen at all.
>
> After all that it isn't working as expected. the SA's get set up 
> correctly based on the initiators socket (I'm using semanage_t in this 
> case) but the reciever SA's aren't set up with the receiving process 
> socket context so I get:
>
> Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
> root:system_r:semanage_t:s0-s0:c0.c255
>
> no matter what context the server is running in.
>
> Further, once that SA is created all domains can use it and it retains 
> the same context, if I rerun the client in unconfined_t I still get:
>
> Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
> root:system_r:semanage_t:s0-s0:c0.c255
>
> I am running in permissive (I'd hope that wouldn't affect this but I 
> can see how it could) because my policy doesn't yet have flow_in and 
> flow_out permissions (any chance to get a policy patch? :) )
>
> Am I off base here, is this the expected results? 
On the bright side localhost connections seem to work well:
# ./client 127.0.0.1
Received: Hello, root:system_r:unconfined_t:s0-s0:c0.c255 from 
root:system_r:semanage_t:s0-s0:c0.c255

so getpeercon got the right answer on both sides.

--
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: [redhat-lspp] Re: RHEL5 Kernel with labeled networking

[Stephen Smalley]

On Tue, 2006-10-03 at 12:08 -0400, James Morris wrote:
> On Tue, 3 Oct 2006, Eric Paris wrote:
> 
> > I think there is going to need to be a policy change that I'm actually
> > talking with Dan about as I type this e-mail.  I think we  need
> > 
> > allow $1 unlabeled_t:packet { flow_in flow_out };
> > 
> > to be added to policy to allow things to work as they did.  I'll post
> > again as soon as we have a policy that appears to let normal networking
> > work in enforcing.
> 
> We need this policy in rawhide before the kernel patches are merged 
> upstream, so we can note the required policy version associated with the 
> patches.  We've do not want to kill Andrew Morton's box again with this 
> kind of thing.

The compat_net support should avoid such breakage, and compat_net is
enabled by default in a default kernel config (just not in the Fedora
kernel config).

-- 
Stephen Smalley
National Security Agency


--
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: [redhat-lspp] Re: RHEL5 Kernel with labeled networking

[Daniel J Walsh]

James Morris wrote:
> On Tue, 3 Oct 2006, Eric Paris wrote:
>
>   
>> I think there is going to need to be a policy change that I'm actually
>> talking with Dan about as I type this e-mail.  I think we  need
>>
>> allow $1 unlabeled_t:packet { flow_in flow_out };
>>
>> to be added to policy to allow things to work as they did.  I'll post
>> again as soon as we have a policy that appears to let normal networking
>> work in enforcing.
>>     
>
> We need this policy in rawhide before the kernel patches are merged 
> upstream, so we can note the required policy version associated with the 
> patches.  We've do not want to kill Andrew Morton's box again with this 
> kind of thing.
>
>
> - James
>   
selinux-policy-2.3.18-2 has this policy.

--
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: RHEL5 Kernel with labeled networking

[Paul Moore]

Eric Paris wrote:
> DO NOT USE THESE KERNELS ON A PRODUCTION SYSTEM!
> 
> If you go to http://people.redhat.com/eparis/RHEL5_labeled_networking/
> you should find a set of kernels based off of the Red Hat RHEL5 source
> tree.  These should include patches for 
> 
> network labeling support from Venkat
> netlabel auditing
> ipsec/secmark secid reconciliation
> netlabel secid reconciliation
> 
> I need a very fast response from everyone involved if these kernels
> 
> A) boot
> B) run without labeled networking (very very important)
> C) run with labeled networking
> 
> If you run across a problem feel free to let me or the list know.  You
> may also feel free to open a bug in bugzilla.redhat.com for the product
> choose Red Hat Enterprise Linux Public Beta and RHEL5.  If you open a
> bug for this labeled networking you can go ahead and assign it to
> eparis@redhat.com so I'm sure to see it and bug the correct people.

So far in my testing I've noticed two things related to "C" using
NetLabel and neither seem to be specific to the RHEL5 backport.  I'm
just getting a handle on both of these issues so no patches yet but I
will keep everybody up to date as things progress.

The first is a race condition with the NetLabel cache caused when
NetLabel returns a cached security attribute to the LSM layer at the
same time that the cache is being invalidated (NOTE: case "B" should not
be affected).  The result is an Oops with
selinux_netlbl_secattr_to_sid() in the stack.  I think I have settled on
a reasonable fix for this, but I want to dwell on it a bit more.  In the
meantime the workaround is to disable the cache:

 # sysctl -w net.ipv4.cipso_cache_enable=0

The second issue is more of a correctness problem in
selinux_ip_postroute_last() and selinux_skb_flow_out() related to what
NetLabel uses as it's "base SID"; the changes made in the "v3" draft of
the patch messed this up a bit.  It's important to note this shouldn't
cause any sort of panic/oops/etc. it just results in a incorrect
NetLabel context when NetLabel is configured (i.e. case "B" should not
be affected).

I'll have more information, patches, bugzillas, etc. as things progress.

-- 
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: RHEL5 Kernel with labeled networking

[Venkat Yekkirala]

> Only if you set /selinux/compat_net to 1.
> Otherwise, you need modified policy to define and allow 
> flow_in/flow_out
> permissions as required, and I suspect you need more in order to deal
> with the fact that we now get labeled traffic on loopback by default
> (thus affecting packet send/recv as well).  Venkat, do you 
> have a policy
> patch?

Will post one in a couple of hours.

--
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: RHEL5 Kernel with labeled networking

[Joy Latten]

>Before network labeling is completed we still need some work
>implementing how we plan to audit configuration changes in ipsec
>labeling decisions.  I believe we agreed today that this auditing must
>be done in kernelspace since we do not have fine grained enough controls
>on netlink messages to allow for all of the auditing in userspace.
>

I've talked to Klaus about what needs to be audited for ipsec and
lspp compliance. I will begin work on a patch and get this out
to the list as soon as I can. We will audit everytime a policy is 
added/removed to/from the ipsec policy database.

Regards,
Joy 

--
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: RHEL5 Kernel with labeled networking

[Joshua Brindle]

Joy Latten wrote:
>> Before network labeling is completed we still need some work
>> implementing how we plan to audit configuration changes in ipsec
>> labeling decisions.  I believe we agreed today that this auditing must
>> be done in kernelspace since we do not have fine grained enough controls
>> on netlink messages to allow for all of the auditing in userspace.
>>
>>     
>
> I've talked to Klaus about what needs to be audited for ipsec and
> lspp compliance. I will begin work on a patch and get this out
> to the list as soon as I can. We will audit everytime a policy is 
> added/removed to/from the ipsec policy database.
>
>   
why not just auditallow all association setcontext?

--
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: RHEL5 Kernel with labeled networking

[Joy Latten]

On Tue, 2006-10-03 at 15:18 -0400, Joshua Brindle wrote:
> Joy Latten wrote:
> >> Before network labeling is completed we still need some work
> >> implementing how we plan to audit configuration changes in ipsec
> >> labeling decisions.  I believe we agreed today that this auditing must
> >> be done in kernelspace since we do not have fine grained enough controls
> >> on netlink messages to allow for all of the auditing in userspace.
> >>
> >>     
> >
> > I've talked to Klaus about what needs to be audited for ipsec and
> > lspp compliance. I will begin work on a patch and get this out
> > to the list as soon as I can. We will audit everytime a policy is 
> > added/removed to/from the ipsec policy database.
> >
> >   
> why not just auditallow all association setcontext?

Dang! Why didn't I think of that! :-) 
Such a good idea. I will do a quick test and
show Klaus and see if it all looks ok to him.
Thanks!!!

Regards,
Joy

--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Joy Latten wrote:
> On Tue, 2006-10-03 at 15:18 -0400, Joshua Brindle wrote:
> 
>>Joy Latten wrote:
>>
>>>>Before network labeling is completed we still need some work
>>>>implementing how we plan to audit configuration changes in ipsec
>>>>labeling decisions.  I believe we agreed today that this auditing must
>>>>be done in kernelspace since we do not have fine grained enough controls
>>>>on netlink messages to allow for all of the auditing in userspace.
>>>>
>>>>    
>>>
>>>I've talked to Klaus about what needs to be audited for ipsec and
>>>lspp compliance. I will begin work on a patch and get this out
>>>to the list as soon as I can. We will audit everytime a policy is 
>>>added/removed to/from the ipsec policy database.
>>>
>>>  
>>
>>why not just auditallow all association setcontext?
> 
> 
> Dang! Why didn't I think of that! :-) 
> Such a good idea. I will do a quick test and
> show Klaus and see if it all looks ok to him.
> Thanks!!!

If we go the auditallow route then we lose some audit record management
features, like the ability to enable/disble/search for these records,
don't we?  Do we care?

-- ljk



--
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: RHEL5 Kernel with labeled networking

[Joshua Brindle]

Linda Knippers wrote:
> Joy Latten wrote:
>   
>> On Tue, 2006-10-03 at 15:18 -0400, Joshua Brindle wrote:
>>
>>     
>>> Joy Latten wrote:
>>>
>>>       
>>>>> Before network labeling is completed we still need some work
>>>>> implementing how we plan to audit configuration changes in ipsec
>>>>> labeling decisions.  I believe we agreed today that this auditing must
>>>>> be done in kernelspace since we do not have fine grained enough controls
>>>>> on netlink messages to allow for all of the auditing in userspace.
>>>>>
>>>>>    
>>>>>           
>>>> I've talked to Klaus about what needs to be audited for ipsec and
>>>> lspp compliance. I will begin work on a patch and get this out
>>>> to the list as soon as I can. We will audit everytime a policy is 
>>>> added/removed to/from the ipsec policy database.
>>>>
>>>>  
>>>>         
>>> why not just auditallow all association setcontext?
>>>       
>> Dang! Why didn't I think of that! :-) 
>> Such a good idea. I will do a quick test and
>> show Klaus and see if it all looks ok to him.
>> Thanks!!!
>>     
>
> If we go the auditallow route then we lose some audit record management
> features, like the ability to enable/disble/search for these records,
> don't we?  Do we care?
>
>   
enable and disable with a boolean

searching? surely you can search avc records..

--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Joshua Brindle wrote:
> Linda Knippers wrote:
> 
>> Joy Latten wrote:
>>  
>>
>>> On Tue, 2006-10-03 at 15:18 -0400, Joshua Brindle wrote:
>>>
>>>    
>>>
>>>> Joy Latten wrote:
>>>>
>>>>      
>>>>
>>>>>> Before network labeling is completed we still need some work
>>>>>> implementing how we plan to audit configuration changes in ipsec
>>>>>> labeling decisions.  I believe we agreed today that this auditing
>>>>>> must
>>>>>> be done in kernelspace since we do not have fine grained enough
>>>>>> controls
>>>>>> on netlink messages to allow for all of the auditing in userspace.
>>>>>>
>>>>>>              
>>>>>
>>>>> I've talked to Klaus about what needs to be audited for ipsec and
>>>>> lspp compliance. I will begin work on a patch and get this out
>>>>> to the list as soon as I can. We will audit everytime a policy is
>>>>> added/removed to/from the ipsec policy database.
>>>>>
>>>>>  
>>>>>         
>>>>
>>>> why not just auditallow all association setcontext?
>>>>       
>>>
>>> Dang! Why didn't I think of that! :-) Such a good idea. I will do a
>>> quick test and
>>> show Klaus and see if it all looks ok to him.
>>> Thanks!!!
>>>     
>>
>>
>> If we go the auditallow route then we lose some audit record management
>> features, like the ability to enable/disble/search for these records,
>> don't we?  Do we care?
>>
>>   
> 
> enable and disable with a boolean
> 
> searching? surely you can search avc records..

I meant with the audit tools, so using auditctl to add/remove rules and
ausearch for looking for specific record types.

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Karl MacMillan]

Linda Knippers wrote:
> Joshua Brindle wrote:
>   
>> Linda Knippers wrote:
>>
>>     
<snip>
>>>
>>> If we go the auditallow route then we lose some audit record management
>>> features, like the ability to enable/disble/search for these records,
>>> don't we?  Do we care?
>>>
>>>   
>>>       
>> enable and disable with a boolean
>>
>> searching? surely you can search avc records..
>>     
>
> I meant with the audit tools, so using auditctl to add/remove rules and
> ausearch for looking for specific record types.
>
>   

As I said in my other mail the searching should be fine. Why does the 
addition or removal need to be handled by auditctl?

Karl


--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Karl MacMillan wrote:
> Linda Knippers wrote:
> 
>> Joshua Brindle wrote:
>>  
>>
>>> Linda Knippers wrote:
>>>
>>>     
> 
> <snip>
> 
>>>> If we go the auditallow route then we lose some audit record management
>>>> features, like the ability to enable/disble/search for these records,
>>>> don't we?  Do we care?
>>>
>>> enable and disable with a boolean
>>>
>>> searching? surely you can search avc records..
>>
>> I meant with the audit tools, so using auditctl to add/remove rules and
>> ausearch for looking for specific record types.
>>   
>  
> As I said in my other mail the searching should be fine. Why does the
> addition or removal need to be handled by auditctl?

There was a discussion a long, long time about about how administrators should
manage what gets into the audit logs, whether its with the audit tools, the
policy or both.  There are explicit message types for alot of management
operations so that the admin can decide whether to get them and the tools
make it easy to search for.  If changing the ipsec label configuration is just
an AVC message, it will be different from just about everything else.  It might
be easy, but is it what we want?

I wish sgrubb were reading mail today.  I think this is something that he
cares about, at least he did the last time we had this conversation.

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Joshua Brindle]

Linda Knippers wrote:
> Karl MacMillan wrote:
>   
>> Linda Knippers wrote:
>>
>>     
>>> Joshua Brindle wrote:
>>>  
>>>
>>>       
>>>> Linda Knippers wrote:
>>>>
>>>>     
>>>>         
>> <snip>
>>
>>     
>>>>> If we go the auditallow route then we lose some audit record management
>>>>> features, like the ability to enable/disble/search for these records,
>>>>> don't we?  Do we care?
>>>>>           
>>>> enable and disable with a boolean
>>>>
>>>> searching? surely you can search avc records..
>>>>         
>>> I meant with the audit tools, so using auditctl to add/remove rules and
>>> ausearch for looking for specific record types.
>>>   
>>>       
>>  
>> As I said in my other mail the searching should be fine. Why does the
>> addition or removal need to be handled by auditctl?
>>     
>
> There was a discussion a long, long time about about how administrators should
> manage what gets into the audit logs, whether its with the audit tools, the
> policy or both.  There are explicit message types for alot of management
> operations so that the admin can decide whether to get them and the tools
> make it easy to search for.  If changing the ipsec label configuration is just
> an AVC message, it will be different from just about everything else.  It might
> be easy, but is it what we want?
>
>   
what about relabeling files? or setting secmark labels? or domain 
transitions? setexec(), etc. I'm very skeptical that lspp requires any 
kind of auditing of ipsec label change but none of these. Further, all 
the others are in policy, you want to special case ipsec? and for that 
matter just the spd rules which is pretty much useless without 
accompanying polmatch rules. I'm very dubious about this entire thread.

> I wish sgrubb were reading mail today.  I think this is something that he
> cares about, at least he did the last time we had this conversation.
>   


--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Joshua Brindle wrote:
> Linda Knippers wrote:
>> Karl MacMillan wrote:
>>> Linda Knippers wrote:
>>>> Joshua Brindle wrote:
>>>>> Linda Knippers wrote:
>>>>>
>>>
>>> <snip>
>>>
>>>    
>>>
>>>>>> If we go the auditallow route then we lose some audit record
>>>>>> management
>>>>>> features, like the ability to enable/disble/search for these records,
>>>>>> don't we?  Do we care?
>>>>>>           
>>>>>
>>>>> enable and disable with a boolean
>>>>>
>>>>> searching? surely you can search avc records..
>>>>>         
>>>>
>>>> I meant with the audit tools, so using auditctl to add/remove rules and
>>>> ausearch for looking for specific record types.
>>>>         
>>>
>>>  
>>> As I said in my other mail the searching should be fine. Why does the
>>> addition or removal need to be handled by auditctl?
>>>     
>>
>>
>> There was a discussion a long, long time about about how
>> administrators should
>> manage what gets into the audit logs, whether its with the audit
>> tools, the
>> policy or both.  There are explicit message types for alot of management
>> operations so that the admin can decide whether to get them and the tools
>> make it easy to search for.  If changing the ipsec label configuration
>> is just
>> an AVC message, it will be different from just about everything else. 
>> It might
>> be easy, but is it what we want?
>>
>>   
> 
> what about relabeling files? or setting secmark labels? or domain
> transitions? setexec(), etc. I'm very skeptical that lspp requires any
> kind of auditing of ipsec label change but none of these. 

It has a requirement to be able to audit all modifications of the
values of security attributes, so we can audit a bunch of syscalls
that do that (chmod, chown, setxattr, ...).  Relabeling files
would definitely count and be covered.  There's also a requirement about
auditing changes to the way data is imported/exported, so this is where
the networking stuff comes in.  I don't know about domain transitions.

> Further, all
> the others are in policy, you want to special case ipsec? and for that
> matter just the spd rules which is pretty much useless without
> accompanying polmatch rules. I'm very dubious about this entire thread.

I'm not trying to special case ipsec.  In fact, that was the point of
my comment.  In general, we have explicit message types for the things
that we care about auditing.  Paul added auditing for the netlabel
configuration changes because the only other way to know about the
changes would be watching the netlink messages.

I asked the question about using auditallow because its different from
how all the other things that lspp cares about are handled from an
audit administrator's perspective.  I personally don't care that much
either way but if its going to be different, folks ought to know,
especially the folks who have to document and test it.

-- ljk
> 
>> I wish sgrubb were reading mail today.  I think this is something that he
>> cares about, at least he did the last time we had this conversation.
>>   
> 
> 


--
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: RHEL5 Kernel with labeled networking

[Stephen Smalley]

On Tue, 2006-10-03 at 18:59 -0400, Linda Knippers wrote:
> Joshua Brindle wrote:
> > Linda Knippers wrote:
> >> Karl MacMillan wrote:
> >>> Linda Knippers wrote:
> >>>> Joshua Brindle wrote:
> >>>>> Linda Knippers wrote:
> >>>>>
> >>>
> >>> <snip>
> >>>
> >>>    
> >>>
> >>>>>> If we go the auditallow route then we lose some audit record
> >>>>>> management
> >>>>>> features, like the ability to enable/disble/search for these records,
> >>>>>> don't we?  Do we care?
> >>>>>>           
> >>>>>
> >>>>> enable and disable with a boolean
> >>>>>
> >>>>> searching? surely you can search avc records..
> >>>>>         
> >>>>
> >>>> I meant with the audit tools, so using auditctl to add/remove rules and
> >>>> ausearch for looking for specific record types.
> >>>>         
> >>>
> >>>  
> >>> As I said in my other mail the searching should be fine. Why does the
> >>> addition or removal need to be handled by auditctl?
> >>>     
> >>
> >>
> >> There was a discussion a long, long time about about how
> >> administrators should
> >> manage what gets into the audit logs, whether its with the audit
> >> tools, the
> >> policy or both.  There are explicit message types for alot of management
> >> operations so that the admin can decide whether to get them and the tools
> >> make it easy to search for.  If changing the ipsec label configuration
> >> is just
> >> an AVC message, it will be different from just about everything else. 
> >> It might
> >> be easy, but is it what we want?
> >>
> >>   
> > 
> > what about relabeling files? or setting secmark labels? or domain
> > transitions? setexec(), etc. I'm very skeptical that lspp requires any
> > kind of auditing of ipsec label change but none of these. 
> 
> It has a requirement to be able to audit all modifications of the
> values of security attributes, so we can audit a bunch of syscalls
> that do that (chmod, chown, setxattr, ...).  Relabeling files
> would definitely count and be covered.  There's also a requirement about
> auditing changes to the way data is imported/exported, so this is where
> the networking stuff comes in.  I don't know about domain transitions.
> 
> > Further, all
> > the others are in policy, you want to special case ipsec? and for that
> > matter just the spd rules which is pretty much useless without
> > accompanying polmatch rules. I'm very dubious about this entire thread.
> 
> I'm not trying to special case ipsec.  In fact, that was the point of
> my comment.  In general, we have explicit message types for the things
> that we care about auditing.  Paul added auditing for the netlabel
> configuration changes because the only other way to know about the
> changes would be watching the netlink messages.
> 
> I asked the question about using auditallow because its different from
> how all the other things that lspp cares about are handled from an
> audit administrator's perspective.  I personally don't care that much
> either way but if its going to be different, folks ought to know,
> especially the folks who have to document and test it.

As I recall, auditallow was deemed acceptable for auditing of writing to
the /proc/self/attr nodes earlier on redhat-lspp.  Note that auditallow
yields not only the avc audit message but also causes a syscall audit
record to be emitted upon syscall exit.  The best thing to do is to
actually try it and see whether the resulting data meets your need.

-- 
Stephen Smalley
National Security Agency


--
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: RHEL5 Kernel with labeled networking

[Linda Knippers]

Stephen Smalley wrote:
> On Tue, 2006-10-03 at 18:59 -0400, Linda Knippers wrote:
> 
>>Joshua Brindle wrote:
>>
>>>Linda Knippers wrote:
>>>
>>>>Karl MacMillan wrote:
>>>>
>>>>>Linda Knippers wrote:
>>>>>
>>>>>>Joshua Brindle wrote:
>>>>>>
>>>>>>>Linda Knippers wrote:
>>>>>>>
>>>>>
>>>>>>>>If we go the auditallow route then we lose some audit record
>>>>>>>>management
>>>>>>>>features, like the ability to enable/disble/search for these records,
>>>>>>>>don't we?  Do we care?
>>>>>>>>          
>>>>>>>
>>>>>>>enable and disable with a boolean
>>>>>>>
>>>>>>>searching? surely you can search avc records..
>>>>>>>        
>>>>>>
>>>>>>I meant with the audit tools, so using auditctl to add/remove rules and
>>>>>>ausearch for looking for specific record types.
>>>>>>        
>>>>>
>>>>> 
>>>>>As I said in my other mail the searching should be fine. Why does the
>>>>>addition or removal need to be handled by auditctl?
>>>>>    
>>>>
>>>>
>>>>There was a discussion a long, long time about about how
>>>>administrators should
>>>>manage what gets into the audit logs, whether its with the audit
>>>>tools, the
>>>>policy or both.  There are explicit message types for alot of management
>>>>operations so that the admin can decide whether to get them and the tools
>>>>make it easy to search for.  If changing the ipsec label configuration
>>>>is just
>>>>an AVC message, it will be different from just about everything else. 
>>>>It might
>>>>be easy, but is it what we want?
>>>>
>>>>  
>>>
>>>what about relabeling files? or setting secmark labels? or domain
>>>transitions? setexec(), etc. I'm very skeptical that lspp requires any
>>>kind of auditing of ipsec label change but none of these. 
>>
>>It has a requirement to be able to audit all modifications of the
>>values of security attributes, so we can audit a bunch of syscalls
>>that do that (chmod, chown, setxattr, ...).  Relabeling files
>>would definitely count and be covered.  There's also a requirement about
>>auditing changes to the way data is imported/exported, so this is where
>>the networking stuff comes in.  I don't know about domain transitions.
>>
>>
>>>Further, all
>>>the others are in policy, you want to special case ipsec? and for that
>>>matter just the spd rules which is pretty much useless without
>>>accompanying polmatch rules. I'm very dubious about this entire thread.
>>
>>I'm not trying to special case ipsec.  In fact, that was the point of
>>my comment.  In general, we have explicit message types for the things
>>that we care about auditing.  Paul added auditing for the netlabel
>>configuration changes because the only other way to know about the
>>changes would be watching the netlink messages.
>>
>>I asked the question about using auditallow because its different from
>>how all the other things that lspp cares about are handled from an
>>audit administrator's perspective.  I personally don't care that much
>>either way but if its going to be different, folks ought to know,
>>especially the folks who have to document and test it.
> 
> 
> As I recall, auditallow was deemed acceptable for auditing of writing to
> the /proc/self/attr nodes earlier on redhat-lspp.  Note that auditallow
> yields not only the avc audit message but also causes a syscall audit
> record to be emitted upon syscall exit.  The best thing to do is to
> actually try it and see whether the resulting data meets your need.

Thanks for the reminder about that thread.
https://www.redhat.com/archives/redhat-lspp/2006-August/msg00008.html

I didn't really see a conclusion though.  Dan was waiting to hear from
Steve.  Steve didn't like it for the reasons I mentioned above.  Were
the auditallows added to the MLS policy?  Did anyone create a module?

-- ljk

--
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: RHEL5 Kernel with labeled networking

[Karl MacMillan]

Joshua Brindle wrote:
>
> Linda Knippers wrote:
<snip>
>>
>> If we go the auditallow route then we lose some audit record management
>> features, like the ability to enable/disble/search for these records,
>> don't we?  Do we care?
>>
>>   
> enable and disable with a boolean
>
> searching? surely you can search avc records..
>

Of course - the avc records are just audit records so the searching / 
reduction / etc. should be fine with the existing audit tools.

Karl


--
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: RHEL5 Kernel with labeled networking

[Joy Latten]

>DO NOT USE THESE KERNELS ON A PRODUCTION SYSTEM!
>
>If you go to http://people.redhat.com/eparis/RHEL5_labeled_networking/
>you should find a set of kernels based off of the Red Hat RHEL5 source
>tree.  These should include patches for 
>
>network labeling support from Venkat
>netlabel auditing
>ipsec/secmark secid reconciliation
>netlabel secid reconciliation
>
>I need a very fast response from everyone involved if these kernels
>
>A) boot
>B) run without labeled networking (very very important)
>C) run with labeled networking
>
>If you run across a problem feel free to let me or the list know.  You
>may also feel free to open a bug in bugzilla.redhat.com for the product
>choose Red Hat Enterprise Linux Public Beta and RHEL5.  If you open a
>bug for this labeled networking you can go ahead and assign it to
>eparis@redhat.com so I'm sure to see it and bug the correct people.
>
>At this time there is a known ipsec problem with these kernels.  I
>haven't looked at it closely but I believe the problem is that processes
>which intend to send over an ipsec tunnels but have certain avc denials
>will actually cause traffic to flow unencrypted.  SO PLEASE DO NOT USE
>THESE ON ANY PRODUCTION SYSTEM!!  There is work going on upstream (on
>linux-netdev not either of these lists) to fix this issue in the 2.6-net
>tree and when it is finished it will get brought back into RHEL5.  (I
>don't think you will hit this bug with relatively modern policy but it
>is there and can be a serious security flaw)
>
>Before network labeling is completed we still need some work
>implementing how we plan to audit configuration changes in ipsec
>labeling decisions.  I believe we agreed today that this auditing must
>be done in kernelspace since we do not have fine grained enough controls
>on netlink messages to allow for all of the auditing in userspace.

A stress test sending streams of tcp and udp packets completed
a 15 hour run successfully. Purpose was to regression test.

Configuration:
non-labeled ipsec, encryption and authentication, 
transport mode using racoon
selinux-policy-mls-2.3.16-2 in permissive
hardware: 2 pseries lpars

I plan to run a stress test using labels with ipsec tonight.

Regards,
Joy

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