[refpolicy] Fwd: Re: system_logging.patch

[refpolicy] Fwd: Re: system_logging.patch

[Daniel J Walsh]

Can you comment on the levels of the sockets


-------- Original Message --------
Subject: 	Re: system_logging.patch
Date: 	Wed, 17 Mar 2010 14:40:11 -0400
From: 	Christopher J. PeBenito <cpebenito@tresys.com>
Organization: 	Tresys Technology, LLC
To: 	Daniel J Walsh <dwalsh@redhat.com>
CC: 	refpolicy at oss1.tresys.com



On Tue, 2010-02-23 at 17:16 -0500, Daniel J Walsh wrote:
>  http://people.fedoraproject.org/~dwalsh/SELinux/F13/system_logging.patch
>
>  New log context
>
>  Allow setting audit tty
>
>  Fixing interfaces

Why are the sockets being set to system high?  Same thing for the pid
file?  They don't have sensitive data.

The logging_manage_all_logs() change is excessive, as "manage" doesn't
include relabeling.

Why does auditd need to use nsswitch?

Otherwise merged.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100318/9014d0dc/attachment.html 

[refpolicy] Fwd: Re: system_logging.patch

[Christopher J. PeBenito]

On Thu, 2010-03-18 at 16:15 -0400, Steve Grubb wrote:
> On Thursday 18 March 2010 01:12:36 pm Daniel J Walsh wrote:
> > >  New log context
> > >  Allow setting audit tty
> > >  Fixing interfaces
> > 
> > Why are the sockets being set to system high?  Same thing for the pid
> > file?  They don't have sensitive data.
> 
> /var/run/audispd_events and the pid file is the only thing I recognize as being 
> from the audit system. The audit system and everything related to it must be 
> at system high.

Again, why?  The socket and pid file do not have sensitive data.  The
daemon and the log files have the sensitive data.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Fwd: Re: system_logging.patch

[Daniel J Walsh]

On 03/19/2010 08:14 AM, Christopher J. PeBenito wrote:
> On Thu, 2010-03-18 at 16:15 -0400, Steve Grubb wrote:
>    
>> On Thursday 18 March 2010 01:12:36 pm Daniel J Walsh wrote:
>>      
>>>>   New log context
>>>>   Allow setting audit tty
>>>>   Fixing interfaces
>>>>          
>>> Why are the sockets being set to system high?  Same thing for the pid
>>> file?  They don't have sensitive data.
>>>        
>> /var/run/audispd_events and the pid file is the only thing I recognize as being
>> from the audit system. The audit system and everything related to it must be
>> at system high.
>>      
> Again, why?  The socket and pid file do not have sensitive data.  The
> daemon and the log files have the sensitive data.
>
>    
So your saying the ability to connect to the socket is going to be 
blocked on the connecto based on the level of the process on the other 
end of the socket.

setroubleshoot_t:SystemLow is not going to be able to connectto 
auditd_t:SystemHigh no matter what the socket and pid file are labeled.

[refpolicy] Fwd: Re: system_logging.patch

[Christopher J. PeBenito]

On Fri, 2010-03-19 at 08:22 -0400, Daniel J Walsh wrote:
> On 03/19/2010 08:14 AM, Christopher J. PeBenito wrote:
> > On Thu, 2010-03-18 at 16:15 -0400, Steve Grubb wrote:
> >    
> >> On Thursday 18 March 2010 01:12:36 pm Daniel J Walsh wrote:
> >>      
> >>>>   New log context
> >>>>   Allow setting audit tty
> >>>>   Fixing interfaces
> >>>>          
> >>> Why are the sockets being set to system high?  Same thing for the pid
> >>> file?  They don't have sensitive data.
> >>>        
> >> /var/run/audispd_events and the pid file is the only thing I recognize as being
> >> from the audit system. The audit system and everything related to it must be
> >> at system high.
> >>      
> > Again, why?  The socket and pid file do not have sensitive data.  The
> > daemon and the log files have the sensitive data.
> >
> >    
> So your saying the ability to connect to the socket is going to be 
> blocked on the connecto based on the level of the process on the other 
> end of the socket.
>
> setroubleshoot_t:SystemLow is not going to be able to connectto 
> auditd_t:SystemHigh no matter what the socket and pid file are labeled.

I'm not sure what you're trying to argue.  The connectto is of course
going to be checked if a connect gets past the MAC write check on the
sock_file.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Fwd: Re: system_logging.patch

[Daniel J Walsh]

On 03/19/2010 10:13 AM, Christopher J. PeBenito wrote:
> On Fri, 2010-03-19 at 08:22 -0400, Daniel J Walsh wrote:
>    
>> On 03/19/2010 08:14 AM, Christopher J. PeBenito wrote:
>>      
>>> On Thu, 2010-03-18 at 16:15 -0400, Steve Grubb wrote:
>>>
>>>        
>>>> On Thursday 18 March 2010 01:12:36 pm Daniel J Walsh wrote:
>>>>
>>>>          
>>>>>>    New log context
>>>>>>    Allow setting audit tty
>>>>>>    Fixing interfaces
>>>>>>
>>>>>>              
>>>>> Why are the sockets being set to system high?  Same thing for the pid
>>>>> file?  They don't have sensitive data.
>>>>>
>>>>>            
>>>> /var/run/audispd_events and the pid file is the only thing I recognize as being
>>>> from the audit system. The audit system and everything related to it must be
>>>> at system high.
>>>>
>>>>          
>>> Again, why?  The socket and pid file do not have sensitive data.  The
>>> daemon and the log files have the sensitive data.
>>>
>>>
>>>        
>> So your saying the ability to connect to the socket is going to be
>> blocked on the connecto based on the level of the process on the other
>> end of the socket.
>>
>> setroubleshoot_t:SystemLow is not going to be able to connectto
>> auditd_t:SystemHigh no matter what the socket and pid file are labeled.
>>      
> I'm not sure what you're trying to argue.  The connectto is of course
> going to be checked if a connect gets past the MAC write check on the
> sock_file.
>
>    
I am agreeing with you, by saying the connectto check will block no 
matter what the socket permission is.

But on Steve's point of view.  We would have to jump through hoops to 
get auditd to create the pid file and socket at SystemLow, Since it runs 
at SystemHigh.

[refpolicy] Fwd: Re: system_logging.patch

[Christopher J. PeBenito]

On Fri, 2010-03-19 at 09:44 -0400, Steve Grubb wrote:
> On Friday 19 March 2010 08:14:57 am Christopher J. PeBenito wrote:
> > On Thu, 2010-03-18 at 16:15 -0400, Steve Grubb wrote:
> > > On Thursday 18 March 2010 01:12:36 pm Daniel J Walsh wrote:
> > > > >  New log context
> > > > >  Allow setting audit tty
> > > > >  Fixing interfaces
> > > > 
> > > > Why are the sockets being set to system high?  Same thing for the pid
> > > > file?  They don't have sensitive data.
> > > 
> > > /var/run/audispd_events and the pid file is the only thing I recognize as
> > > being from the audit system. The audit system and everything related to
> > > it must be at system high.
> > 
> > Again, why?  The socket and pid file do not have sensitive data. 

I will take the patch for the audit files because these files are
created by a system high process and thus will be system high;
relabeling shouldn't lower their sensitivity.  I don't agree with any of
the following arguments otherwise.

> The socket is the realtime interface for audit data, so yes its got sensitive 
> data.

No, it is a means to connect to the daemon, like the port in internet
domain sockets (which are all system low in refpolicy).  In my opinion
the process-process connectto permission is where the most
confidentiality-relevant check happens.

> The pid file is high because the audit daemon is. It can be argued that the pid 
> file is used by the initscripts to locate the daemon for signalling to reload, 
> rotate logs, terminate, or other actions that should be limited to the 
> security officer. 

Knowing the pid of the auditd doesn't mean you can do anything to it.
What you seem to be implying is that the integrity of the file needs to
be preserved, which is what TE is for.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Fwd: Re: system_logging.patch

[Daniel J Walsh]

On 03/19/2010 11:02 AM, Steve Grubb wrote:
> On Friday 19 March 2010 10:44:22 am Christopher J. PeBenito wrote:
>    
>>> The socket is the realtime interface for audit data, so yes its got
>>> sensitive  data.
>>>        
>> No, it is a means to connect to the daemon, like the port in internet
>> domain sockets (which are all system low in refpolicy).  In my opinion
>> the process-process connectto permission is where the most
>> confidentiality-relevant check happens.
>>      
> I would keep it high to make sure a process at system low cannot gain access
> to audit data that it should not. Sure, the DAC check will require root. But
> not all root roles are the security officer. There are no checks done by the
> daemon to see who is connecting.
>
>
>    
SELinux will check.
>>> The pid file is high because the audit daemon is. It can be argued that
>>> the pid  file is used by the initscripts to locate the daemon for
>>> signalling to reload, rotate logs, terminate, or other actions that
>>> should be limited to the security officer.
>>>        
>> Knowing the pid of the auditd doesn't mean you can do anything to it.
>> What you seem to be implying is that the integrity of the file needs to
>> be preserved, which is what TE is for.
>>      
> Sure. There is that reason, too.  :)
>
> Thanks,
> -Steve
>