* Steve Grubb (sgrubb(a)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