[redhat-lspp] audit messages during bootup

[Russell Coker]

On Thu, 2006-01-05 at 22:45 -0500, Steve Grubb wrote:
> On Thursday 05 January 2006 21:53, Russell Coker wrote:
> > That depends on when the auditd starts.  Currently auditd starts at
> > number 18 in run level 5, that's after named, portmap, and nfslock. 
> 
> I had it starting after portmap in case someone was using a nfs directory for 
> the audit logs. However, audit-1.1.3, which was released today, has it 
> starting at 11, which is just before syslogd.

I find it difficult to imagine a situation where NFS would be an
appropriate way of dealing with audit data.  I also find it difficult to
imagine why anyone who has a serious need for auditd (as opposed to the
majority who either just want it for SE Linux events or who don't even
know what it is) would even want to run NFS3 on their machines.

My experience with NFS3 is that in the past I have had bad network data
kill the Linux client and server (bug in kernel code) and kill the
Solaris client (Sun regarded it as a bug in the SERVER code which is a
strong indication of their plans for NFS reliability).

I agree however that it's ideal to allow customers to do all manner of
weird things even if we think it's not a good idea.  So what will we do
in the case of NFS mounted /var/log/audit?  Maybe have auditd store data
in memory while waiting for the filesystem to mount?

Would having auditd start after portmap be enough anyway?  Wouldn't it
need to be after netfs at number 25?

> > > Or do we only care about the audit messages that occur once the system is
> > > to a point where someone could attempt login?
> >
> > I think that we only really care about audit messages that occur when
> > the system is capable of performing actions on behalf of users or
> > network data.  When the system is just running kudzu etc there's little
> > need for it.
> 
> What about during autorelabel? Do we care if policy loads? What if policy does 
> not load due to a bad update or something?

If the policy doesn't load and the machine is set to be in enforcing
mode then the machine will halt and there is no need to audit.

Autorelabel is a problem, maybe auditd should be started from rc.sysinit
then?  At the time that autorelabel is about to run the system should be
able to run auditd (all local file systems will be mounted).  Maybe the
correct thing to do in this case would be to start auditd after putting
the machine in permissive mode but before the autorelabel operation (so
a bad file label won't prevent the auditd from being able to log the
correction of the bad label in question).

> > The only exception to this is hotplug.  I believe that a USB device is
> > an external object which can trigger code execution early in the boot
> > process, which is a potential problem for this and other things.
> 
> Do we care about device allocation during boot? Or only the manual changes?

I believe that we care about allocation of things that are different.
If I have a hard disk that's installed inside my computer then I don't
care about it's device being allocated at boot.  If my machine boots
with a USB disk connected then it's something that is possibly connected
to a hostile party and therefore something that I want to have audited.
Incidentally I have had someone use a USB mass-storage device in an
attempt to crack one of my machines, the audit method used was a friend
witnessing the event and telling me about it.