[PATCH] Auditd shutdown credentials

[Chris Wright]

* Steve Grubb (sgrubb at redhat.com) wrote:
> On Wednesday 27 April 2005 16:09, Chris Wright wrote:
> > Thanks, that does fix pure spoofing.  It's still just a best guess since
> > it could be pid from one thread and uid from another (simple spinlock
> > would at least guarantee consistency).
> 
> We don't have a requirement to protect against malicious acts. Policy can be 
> written that locks down who can send a signal to auditd. The initscripts do 
> not use threads. Besides, if you are root, you can change your own loginuid 
> to anything you want. Why bother with threads?

thread or process in this case (i.e. two distinct schedulable entities,
one on each processor), but I see your point

> > If it were queued, you'd be able to replay the history (at a cost).
> 
> This would be using a scud missile to kill a mosquito. The signals are not 
> queued, so what would I do with the extra ones? When would I even read them? 
> On start up? Its not needed.

Heh ;-) fair enough

> > I might have gotten mixed up since this audit.h is different from mine,
> > but it looks like this symbol is declared for CONFIG_AUDIT, whereas
> > definition is under CONFIG_AUDITSYSCALL
> 
> You're right...this could be a problem depending on your file. I'm using the 
> latest 2.6.9 kernel from David's yum repo like was requested. The function 
> prototype is under CONFIG_AUDIT and the macro is in the else clause. The 
> function definition is has no ifdefs around it and its in auditsc.c. Is 
> something wrong?

I think this won't compile then with CONFIG_AUDIT=y and
CONFIG_AUDITSYSCALL=n.  You'll have no macro to turn it off, so
signal.o will be referring to something which doesn't exist.

> > > @@ -429,6 +435,12 @@
> > >                                         NETLINK_CB(skb).pid,
> > >                                         uid, seq, data);
> > >               break;
> > > +     case AUDIT_TERM_INFO:
> > > +             term_data.uid = audit_kill_uid;
> > > +             term_data.pid = audit_kill_pid;
> > > +             audit_send_reply(NETLINK_CB(skb).pid, seq, AUDIT_TERM_INFO,
> > > +                             0, 0, &term_data, sizeof(term_data));
> >
> > Hmmm, there's still room trouble here.  The queue could be full, or you'd
> > still need to drain all messages.
> 
> What queue? audit_send_reply does a netlink unicast.

The socket buffer queue.  The same one that's causing the problem right
now.

> > So you can guarantee that if you read 
> > until queue is empty you either got this message, or it was dropped (not
> > the best guarantee).  
> 
> The corresponding user space code reads the netlink socket until it gets the 
> AUDIT_TERM_INFO packet.

So, the real value here is the well-marked packet?  In which case, a
sub-type (as you've mentioned a few times in other contexts) could be
the simplest solution (no requirement for userspace to ask for kernel to
send with anything more than a simple recv()).  IOW, it's still drain
queue until $event...

> > Would some trivially simple sysfs file help you? 
> 
> That depends on whether something is wrong above.

OK, we can table it for the moment.

> > > @@ -572,6 +584,8 @@
> > >               audit_panic("cannot initialize netlink socket");
> > >  
> > >       audit_initialized = 1;
> > > +     audit_kill_uid = -1;
> > > +     audit_kill_pid = -1;
> >
> > These can go at declaration
> 
> OK.
> 
> > > +     if (unlikely(audit_pid && t->pid == audit_pid)) {
> > > +             if (sig == SIGTERM || sig == SIGKILL) {
> >
> > It's impossible to use on SIGKILL, since auditd can't catch that signal.
> 
> I thought about that after I sent the patch...already changed that. :)
> 
> > Any reason this should be unavailable when syscall auditing is off?
> 
> No. 
> 
> > Perhaps it should be in audit core, and then make the pid/uid bits
> > static again.
> 
> Can't without getting the full definition of audit_context - which is local to 
> auditsc.c. Is it time to move that into the header? I suspect it was local to 
> auditsc to keep people from manipulating it all over the place.

Ahhh, right...I shoulda known that, I've been bitten by it myself ;-)
Short of moving header out, I guess audit_get_loginuid would do the job.

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