From: dwalsh@redhat.com (Daniel J Walsh)
Date: Fri, 19 Mar 2010 11:21:53 -0400
Subject: [refpolicy] Fwd: Re: system_logging.patch
In-Reply-To: <201003191102.56364.sgrubb@redhat.com>
References: <4BA25F04.7030105@redhat.com>
	<201003190944.18262.sgrubb@redhat.com>
	<1269009862.5623.208.camel@gorn.columbia.tresys.com>
	<201003191102.56364.sgrubb@redhat.com>
Message-ID: <4BA39691.7060209@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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
>