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