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

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

[Klaus Weidner]

On Tue, Oct 03, 2006 at 04:40:23PM -0400, 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?

Well, you can permit admins to enable/disable the auditallow rule, that
way people who don't want it aren't bothered by the messages. I don't
think that the LSPP requirement to include/exclude messages by user
identity is intended to apply for administrative actions like this.

Can ausearch handle the auditallow AVC records in the audit log correctly
for common fields such as auid and subject MLS label?

-Klaus

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

[Steve Grubb]

On Tuesday 03 October 2006 17:26, Klaus Weidner wrote:
> Can ausearch handle the auditallow AVC records in the audit log correctly
> for common fields such as auid and subject MLS label?

Yes it can, but there's no way to distinguish the message's proper meaning. 
You get an AVC with granted. How do you figure out that was a configuration 
change?

-Steve

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

[George C. Wilson]

On Wed, Oct 04, 2006 at 12:25:28PM -0400, Steve Grubb wrote:
> On Tuesday 03 October 2006 17:26, Klaus Weidner wrote:
> > Can ausearch handle the auditallow AVC records in the audit log correctly
> > for common fields such as auid and subject MLS label?
> 
> Yes it can, but there's no way to distinguish the message's proper meaning. 
> You get an AVC with granted. How do you figure out that was a configuration 
> change?
> 
> -Steve
>

Agree.  Though the information is in the AVC records, it would be difficult for
an admin to use.  Also, we don't want admins to have to change the policy just
to audit in one particular case.  Joy is looking at adding hooks in the SPD add
and delete paths to fix this.

-- 
George Wilson <ltcgcw@us.ibm.com>
IBM Linux Technology Center

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

[Steve Grubb]

On Tuesday 03 October 2006 16:40, Linda Knippers wrote:
> > 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?

Yes we care! And we should not do it with auditallow rules. The problem is 
that to SE linux, EVERYTHING is an AVC. There is no separation of meaning by 
using the message type. If an admin wants to query to see all the config 
changes made during a range of time, using AVC's will not be considered in 
the results.

There needs to be a new message type for this or we need to consolidate around 
the ones Paul used for netlabel and change them as needed. This allows better 
reporting and understanding of the system's real status.

-Steve


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

[Karl MacMillan]

Steve Grubb wrote:
> On Tuesday 03 October 2006 16:40, Linda Knippers wrote:
>   
>>> 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?
>>     
>
> Yes we care! And we should not do it with auditallow rules. The problem is 
> that to SE linux, EVERYTHING is an AVC. There is no separation of meaning by 
> using the message type. If an admin wants to query to see all the config 
> changes made during a range of time, using AVC's will not be considered in 
> the results.
>
>   

I don't understand - the object class and / or permissions will allow 
filtering and separating out the various types of AVC messages.

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]

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

[Casey Schaufler]

--- Linda Knippers <linda.knippers@hp.com> wrote:


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

I think you would have trouble arguing that
a domain transition is not a change in the
security state of the system. For the evaluations
I worked auditing was required for any change
to uids, gids, capabilities, sensitivity,
integrity, or any other security relevent
attribute.


Casey Schaufler
casey@schaufler-ca.com

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

[Klaus Weidner]

On Tue, Oct 03, 2006 at 04:38:48PM -0700, Casey Schaufler wrote:
> --- Linda Knippers <linda.knippers@hp.com> wrote:
> > 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.
> 
> I think you would have trouble arguing that a domain transition is not
> a change in the security state of the system. For the evaluations I
> worked auditing was required for any change to uids, gids,
> capabilities, sensitivity, integrity, or any other security relevent
> attribute.

Yes, it is a change in the process security state.

Domain transitions are auditable already - dynamic transitions through
the auditallow rules on /proc/$PID/attr/*, and automatic transitions by
putting filesystem watches on the *_exec_t binaries you're interested in.

-Klaus

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

[Joshua Brindle]

Klaus Weidner wrote:
> On Tue, Oct 03, 2006 at 04:38:48PM -0700, Casey Schaufler wrote:
>   
>> --- Linda Knippers <linda.knippers@hp.com> wrote:
>>     
>>> 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.
>>>       
>> I think you would have trouble arguing that a domain transition is not
>> a change in the security state of the system. For the evaluations I
>> worked auditing was required for any change to uids, gids,
>> capabilities, sensitivity, integrity, or any other security relevent
>> attribute.
>>     
>
> Yes, it is a change in the process security state.
>
> Domain transitions are auditable already - dynamic transitions through
> the auditallow rules on /proc/$PID/attr/*, and automatic transitions by
> putting filesystem watches on the *_exec_t binaries you're interested in.
>
>   
Um, you can just auditallow domain domain : process transition for all 
transitions but the point was that they didn't want a mixture of policy 
auditing and audit framework auditing

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

[Karl MacMillan]

Klaus Weidner wrote:
> On Tue, Oct 03, 2006 at 04:38:48PM -0700, Casey Schaufler wrote:
>   
>> --- Linda Knippers <linda.knippers@hp.com> wrote:
>>     
>>> 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.
>>>       
>> I think you would have trouble arguing that a domain transition is not
>> a change in the security state of the system. For the evaluations I
>> worked auditing was required for any change to uids, gids,
>> capabilities, sensitivity, integrity, or any other security relevent
>> attribute.
>>     
>
> Yes, it is a change in the process security state.
>
> Domain transitions are auditable already - dynamic transitions through
> the auditallow rules on /proc/$PID/attr/*,

Just to be clear - this would catch both dynamic transitions (dyntrans) 
and explicitly requested exec transitions. The problem is that the audit 
record will record the request for the security state change and not 
whether it succeeded.

>  and automatic transitions by
> putting filesystem watches on the *_exec_t binaries you're interested in.
>
>   

Josh's suggestion of the auditallow will catch all exec transitions 
without the false positives I mentioned above. I think the impedance 
mismatch between the audit rules and SELinux will make it very hard to 
capture SELinux specific actions in an accurate and natural way.

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

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

[Klaus Weidner]

On Wed, Oct 04, 2006 at 11:20:32AM -0400, Linda Knippers wrote:
> 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?

Yes, it's part of the "lspp_policy" module included in the kickstart
config RPM I posted yesterday.

This reminds me - can we assume that the setsocketcreate and
setipccreate attributes will remain unimplemented for RHEL5? If they get
added at the last minute the people who write the tests would get very
unhappy.

-Klaus

policy_module(lspp_policy,1.0)

gen_require(`
        attribute domain;
')

# Audit setting of security relevant process attributes
# These settings are OPTIONAL
auditallow domain self:process setcurrent;
auditallow domain self:process setexec;
auditallow domain self:process setfscreate;
#auditallow domain self:process setsocketcreate; # FIXME
#auditallow domain self:process setipccreate; # FIXME


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

[Eric Paris]

seipccreate is dead.  it will not be implemented without a user.
setsockcreate i believe is already there....

-Eric

On Wed, 2006-10-04 at 12:41 -0500, Klaus Weidner wrote:
> On Wed, Oct 04, 2006 at 11:20:32AM -0400, Linda Knippers wrote:
> > 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?
> 
> Yes, it's part of the "lspp_policy" module included in the kickstart
> config RPM I posted yesterday.
> 
> This reminds me - can we assume that the setsocketcreate and
> setipccreate attributes will remain unimplemented for RHEL5? If they get
> added at the last minute the people who write the tests would get very
> unhappy.
> 
> -Klaus
> 
> policy_module(lspp_policy,1.0)
> 
> gen_require(`
>         attribute domain;
> ')
> 
> # Audit setting of security relevant process attributes
> # These settings are OPTIONAL
> auditallow domain self:process setcurrent;
> auditallow domain self:process setexec;
> auditallow domain self:process setfscreate;
> #auditallow domain self:process setsocketcreate; # FIXME
> #auditallow domain self:process setipccreate; # FIXME
> 
> --
> redhat-lspp mailing list
> redhat-lspp@redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp


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

[Linda Knippers]

Eric Paris wrote:
> seipccreate is dead.  it will not be implemented without a user.
> setsockcreate i believe is already there....

Yes, I see it in beta 1.

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

[Stephen Smalley]

On Wed, 2006-10-04 at 13:51 -0400, Eric Paris wrote:
> seipccreate is dead.  it will not be implemented without a user.
> setsockcreate i believe is already there....

but not defined in policy (flask/access_vectors) so no one can use it in
policy (but the kernel will deny it unless your allow rule implicitly
grants it via a * or a set complement).

> 
> -Eric
> 
> On Wed, 2006-10-04 at 12:41 -0500, Klaus Weidner wrote:
> > On Wed, Oct 04, 2006 at 11:20:32AM -0400, Linda Knippers wrote:
> > > 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?
> > 
> > Yes, it's part of the "lspp_policy" module included in the kickstart
> > config RPM I posted yesterday.
> > 
> > This reminds me - can we assume that the setsocketcreate and
> > setipccreate attributes will remain unimplemented for RHEL5? If they get
> > added at the last minute the people who write the tests would get very
> > unhappy.
> > 
> > -Klaus
> > 
> > policy_module(lspp_policy,1.0)
> > 
> > gen_require(`
> >         attribute domain;
> > ')
> > 
> > # Audit setting of security relevant process attributes
> > # These settings are OPTIONAL
> > auditallow domain self:process setcurrent;
> > auditallow domain self:process setexec;
> > auditallow domain self:process setfscreate;
> > #auditallow domain self:process setsocketcreate; # FIXME
> > #auditallow domain self:process setipccreate; # FIXME
> > 
> > --
> > redhat-lspp mailing list
> > redhat-lspp@redhat.com
> > https://www.redhat.com/mailman/listinfo/redhat-lspp
> 
> 
> --
> 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.
-- 
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

[Stephen Smalley]

On Wed, 2006-10-04 at 12:41 -0500, Klaus Weidner wrote:
> On Wed, Oct 04, 2006 at 11:20:32AM -0400, Linda Knippers wrote:
> > 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?
> 
> Yes, it's part of the "lspp_policy" module included in the kickstart
> config RPM I posted yesterday.
> 
> This reminds me - can we assume that the setsocketcreate and
> setipccreate attributes will remain unimplemented for RHEL5? If they get
> added at the last minute the people who write the tests would get very
> unhappy.

sockcreate was added in 2.6.18, and thus should be present in the RHEL5
kernel.  ipccreate was not upstreamed due to lack of a user so far.

The actual permission is setsockcreate.  But no one submitted a policy
patch to define it.  Eric?

> 
> -Klaus
> 
> policy_module(lspp_policy,1.0)
> 
> gen_require(`
>         attribute domain;
> ')
> 
> # Audit setting of security relevant process attributes
> # These settings are OPTIONAL
> auditallow domain self:process setcurrent;
> auditallow domain self:process setexec;
> auditallow domain self:process setfscreate;
> #auditallow domain self:process setsocketcreate; # FIXME
> #auditallow domain self:process setipccreate; # FIXME
-- 
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

[Steve Grubb]

On Tuesday 03 October 2006 17:30, Karl MacMillan wrote:
> > 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?

Because we want to teach admins to use the audit system to...audit. Its really 
awkward to tell them that you can audit almost everything, but if you need to 
do this one other thing, you need to change your policy to do it.

Also, the audit system records changes to itself so that you can see when that 
rule disappeared from the config. Doing it in policy, all you get a policy 
loaded message which doesn't tell you what in the policy changed.

-Steve

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

[Venkat Yekkirala]

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

Yes.

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

If you have the contraints from the policy patch I posted last night
applied to your policy, you won't need the above allow rule.

> > Racoon also needed setcontext for unconfined_t unconfined_t 
> (not sure 
> > what the source and target mean here)

The source should be racoon (running in unconfined_t?) and the
target is the new SA context (unconfined_t I suppose).

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

This can happen if, for example, iptables rejects an "unlabeled"
packet with a TCP Reset. The reply packet flow will derive its
label from the original packet (unlabeled in this case).

Other examples are where an outgoing packet would derive its label
from an incoming packet are:

- icmp messages
- tcp resets generated by tcp.
- tcp aknowledgements when the socket is in time_wait and SYN_RCVD states.

One thing to keep in mind is that secid reconciliation occurs AFTER all
the IPSec xfrm(s) are applied (decrypted, decompressed, etc). So the
label a packet has at the point a response is generated (expect the last
2 tcp in the above) might not have been reconciled, and thus could be
carrying whatever label has been defined via secmark.

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

Is the context after Hello, the context returned by getpeercon?

Also, where are you getting the "from" context from?

> >
> > no matter what context the server is running in.

Likely because you are running in permissive mode. ANY process can now
"sendto" the same SA.

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

In fact it does.

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

Are you able to rerun the tests AFTER applying the
constrains from last night's policy patch and while
in enforcing?

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

[Joy Latten]

On Wed, 2006-10-04 at 14:41 -0400, Venkat Yekkirala wrote:
> > > 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.
> 
> Yes.
> 
> > >
> > > 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.
> 
> If you have the contraints from the policy patch I posted last night
> applied to your policy, you won't need the above allow rule.
> 
> > > Racoon also needed setcontext for unconfined_t unconfined_t 
> > (not sure 
> > > what the source and target mean here)
> 
> The source should be racoon (running in unconfined_t?) and the
> target is the new SA context (unconfined_t I suppose).
> 
I was playing around and noticed the same behaviour. I did a ping, which
resulted in kernel sending acquire to racoon. 
I needed "allow sysadm_t ping_t association:setcontext". I had newroled
to sysadm_r when I did the ping and my SA's context was ping_t.
I am guessing in above case, context that started program was
unconfined_t (I think method said he did runcon.) and program which
caused acquire was unconfined_t too.

I have not yet applied the new policy patch, but does it take care of
this?
 
> > >
> > > 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
> 

I saw this too with my ping example, except mine needed
"allow unlabeled_t sysadm_t association:polmatch". I noticed
this occured as the last deny on initiator and first one on receiver,
not that it means anything. Again, I will apply new set of policy
patches and see what happens. 

> This can happen if, for example, iptables rejects an "unlabeled"
> packet with a TCP Reset. The reply packet flow will derive its
> label from the original packet (unlabeled in this case).
> 
> Other examples are where an outgoing packet would derive its label
> from an incoming packet are:
> 
> - icmp messages
> - tcp resets generated by tcp.
> - tcp aknowledgements when the socket is in time_wait and SYN_RCVD states.
> 
> One thing to keep in mind is that secid reconciliation occurs AFTER all
> the IPSec xfrm(s) are applied (decrypted, decompressed, etc). So the
> label a packet has at the point a response is generated (expect the last
> 2 tcp in the above) might not have been reconciled, and thus could be
> carrying whatever label has been defined via secmark.
> 

I noticed something else, and this is perhaps my not understanding
something. In my spd on both sides, the security context was
"system_u:object_r:passwd_t:s2", my SAs, on both sides were created with
"root:sysadm_r:ping_t:s0-s15:c0.c1023". Shouldn't the mls label in my
spd be honored in SA? Should SA be allowed an mls label of s0 or S1, in
this case? Or is it just as long as the "polmatch" succeeds?

In the code security_xfrm_state_alloc_acquire() we pass the fl->secid,
which will be used to acquire the mls label for the SA. I am not sure I 
understand this? Also, when does fl->secid get set on output or do we
care? The only place I see it get set is in
security_xfrm_decode_session(), which eventually gets called via
xfrm_policy_check()/xfrm4_policy_check (which I think gets called on
input) or xfrm_route_forward(). So, for example, my ping created a
packet on output, and I think security_xfrm_decode_session() hasn't been
called. I am not sure what fl->secid will be if not 0... So,
"s0-s15:c0.c1023" was passed in the acquire for the SA. Is this ok or
right?

I need to test labeled ipsec in mls for lspp and need to understand. 

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

[Joshua Brindle]

On Wed, 2006-10-04 at 14:41 -0400, Venkat Yekkirala wrote:
<snip>
> > >
> > > Received: Hello, root:system_r:semanage_t:s0-s0:c0.c255 from 
> > > root:system_r:semanage_t:s0-s0:c0.c255
> 
> Is the context after Hello, the context returned by getpeercon?
> 
> Also, where are you getting the "from" context from?
> 

Ok, the client connects to the server, the server responds with "Hello,
%s" where %s is what is returned from getpeercon(). The client takes
that response and adds "from %s" where %s is what is returned from
getpeercon() so the end result is:

"Hello, %s from %s", client_con, server_con

> > >
> > > no matter what context the server is running in.
> 
> Likely because you are running in permissive mode. ANY process can now
> "sendto" the same SA.
> 

Once Eric rolls a new kernel with the changes from yesterday I'll try it
again in enforcing to see how it works. (net-2.6 is being moody with
me :\ )




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