[PATCH] Auditd shutdown credentials

[Chris Wright]

* Steve Grubb (sgrubb at redhat.com) wrote:
> On Thursday 28 April 2005 16:57, Chris Wright wrote:
> > > 299         memcpy(data, payload, size);
> > > 300         netlink_unicast(audit_sock, skb, pid, MSG_DONTWAIT);
> > > 301         return;
> > >
> > > We don't check the return code from netlink_unicast or handle it. That
> > > needs to be fixed so that we don't lose it.
> >
> > That's exactly what I was trying to get at.  Choices are...it's dropped
> > (silently), or it's in the queue, at which point you're draining in hopes
> > of finding it.
> 
> Yes we are draining trying to find the packet. Just queuing it in the head of 
> the list would be sufficient.

There's not currently an interface to do that ATM (i.e. netlink_unicast does
skb_queue_tail).

> Which brings up the point that this packet has 
> priority over anything else in the queue if its also full. We can dump the 
> whole queue to /dev/null or syslog to make room.

Perhaps multiple channels makes more sense.  It's admin/control plane
vs. data plane.

> Let me throw something out...it came up in some discussions over the SE Linux 
> policy that were implementing that maybe the best solution is to have 2 
> netlink socket types. One for command and control and one for spewing events. 
> This way the command and control channel is always empty. Personally, I think 
> its too late for this idea.

Yeah, I was thinking the same (re: multiple channels), however I don't
know about the time contraints.

> > Which leaves me wondering if the signal hook just does 
> > a simple audit_log_type(TERMINFO, "blah") would be good?  This will hook
> > into the retry logic at least.
> 
> I like the TERMINFO situation better. I think you saw the reasons farther down 
> the list. But...
> 
> I got to thinking about something this afternoon. If we support SIGHUP to 
> reload the audit daemon, we have the same issue...who issued the reload 
> command? We will need to hook SIGHUP as well in that case...and then the name 
> TERMINFO doesn't seem right anymore. :\

Well, could be AUDIT_ADMIN.  Doesn't have to be TERMINFO, that could be
the sub-type, or part of payload.

> > > This reminds me of something I asked for in the past, and that's a
> > > capabilities statement in the get message. It should tell me what
> > > features are compiled in. This will be even more important when we start
> > > doing LSPP since the userspace tools will need to adapt.
> >
> > Seems very reasonable.  What was the list of features you thought were
> > useful?
> 
> We should start a new thread for this.

Good idea.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net