Re: RHEL5 Kernel with labeled networking

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

[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

[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

[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: 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]

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

[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

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

[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

[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

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

[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

[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

[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

[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

[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

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

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.