11:35 a.m.
The attached patch addresses the problem with getting the audit daemon
shutdown credential information. It creates a new message type
AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the
shutdown.
It requires the placement of a hook function that gathers the information. The
hook is after the DAC & MAC checks and before the function returns. Racing
threads could overwrite the uid & pid - but they would have to be root and
have policy that allows signalling the audit daemon. That should be a
manageable risk.
The userspace component will be released later in audit 0.7.2. When it
receives the TERM signal, it queries the kernel for shutdown information.
When it receives it, it writes the message and exits. The message looks
like this:
type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650
uid=525, auditd pid=1685
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
3:09 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
The attached patch addresses the problem with getting the audit
daemon
shutdown credential information. It creates a new message type
AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the
shutdown.
It requires the placement of a hook function that gathers the information. The
hook is after the DAC & MAC checks and before the function returns. Racing
threads could overwrite the uid & pid - but they would have to be root and
have policy that allows signalling the audit daemon. That should be a
manageable risk.
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). If it were queued, you'd be able
to replay the history (at a cost).
The userspace component will be released later in audit 0.7.2. When
it
receives the TERM signal, it queries the kernel for shutdown information.
When it receives it, it writes the message and exits. The message looks
like this:
type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650
uid=525, auditd pid=1685
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
diff -urB linux-2.6.9.orig/include/linux/audit.h
linux-2.6.9/include/linux/audit.h
--- linux-2.6.9.orig/include/linux/audit.h 2005-04-27 11:23:26.000000000 -0400
+++ linux-2.6.9/include/linux/audit.h 2005-04-27 11:22:51.000000000 -0400
@@ -38,6 +38,7 @@
#define AUDIT_WATCH_INS 1007 /* Insert file/dir watch entry */
#define AUDIT_WATCH_REM 1008 /* Remove file/dir watch entry */
#define AUDIT_WATCH_LIST 1009 /* List all watches */
+#define AUDIT_TERM_INFO 1010 /* Get termination information */
#define AUDIT_KERNEL 2000 /* Asynchronous audit record. NOT A REQUEST. */
/* Rule flags */
@@ -201,6 +202,11 @@
};
+struct audit_term_info {
+ uid_t uid;
+ pid_t pid;
+};
+
struct audit_buffer;
struct audit_context;
struct inode;
@@ -297,6 +303,7 @@
int done, int multi,
void *payload, int size);
extern void audit_log_lost(const char *message);
+extern void audit_kill_info(int sig, struct task_struct *t);
#else
#define audit_log(t,f,...) do { ; } while (0)
#define audit_log_start(t) ({ NULL; })
@@ -312,6 +319,7 @@
#define audit_set_backlog_limit(l) do { ; } while (0)
#define audit_set_enabled(s) do { ; } while (0)
#define audit_set_failure(s) do { ; } while (0)
+#define audit_kill_info(s,t) do { ; } while (0)
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
definiion is under CONFIG_AUDITSYSCALL
#endif
#endif
#endif
diff -urB linux-2.6.9.orig/kernel/audit.c linux-2.6.9/kernel/audit.c
--- linux-2.6.9.orig/kernel/audit.c 2005-04-27 11:23:29.000000000 -0400
+++ linux-2.6.9/kernel/audit.c 2005-04-27 11:22:51.000000000 -0400
@@ -68,7 +68,7 @@
/* If audit records are to be written to the netlink socket, audit_pid
* contains the (non-zero) pid. */
-static int audit_pid;
+int audit_pid;
/* If audit_limit is non-zero, limit the rate of sending audit records
* to that number per second. This prevents DoS attacks, but results in
@@ -79,6 +79,10 @@
static int audit_backlog_limit = 64;
static atomic_t audit_backlog = ATOMIC_INIT(0);
+/* The identity of the user shutting down the audit system. */
+uid_t audit_kill_uid;
+pid_t audit_kill_pid;
+
/* Records can be lost in several ways:
0) [suppressed in audit_alloc]
1) out of memory in audit_log_start [kmalloc of struct audit_buffer]
@@ -320,6 +324,7 @@
case AUDIT_DEL:
case AUDIT_WATCH_INS:
case AUDIT_WATCH_REM:
+ case AUDIT_TERM_INFO:
if (!cap_raised(eff_cap, CAP_AUDIT_CONTROL))
err = -EPERM;
break;
@@ -343,6 +348,7 @@
struct audit_buffer *ab;
u16 msg_type = nlh->nlmsg_type;
uid_t loginuid; /* loginuid of sender */
+ struct audit_term_info term_data;
err = audit_netlink_ok(NETLINK_CB(skb).eff_cap, msg_type);
if (err)
@@ -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. 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). Would some trivially simple sysfs file help you?
+ break;
default:
err = -EINVAL;
break;
@@ -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
audit_enabled = audit_default;
audit_filesystem_init();
audit_log(NULL, "initialized");
diff -urB linux-2.6.9.orig/kernel/auditsc.c linux-2.6.9/kernel/auditsc.c
--- linux-2.6.9.orig/kernel/auditsc.c 2005-04-27 11:23:29.000000000 -0400
+++ linux-2.6.9/kernel/auditsc.c 2005-04-27 11:22:51.000000000 -0400
@@ -1134,3 +1134,22 @@
audit_notify_watch_exit:
return ret;
}
+
+void audit_kill_info(int sig, struct task_struct *t)
+{
+ extern pid_t audit_kill_pid;
+ extern uid_t audit_kill_uid;
+ extern int audit_pid;
+
+ 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.
+ struct audit_context *ctx = current->audit_context;
+ audit_kill_pid = current->pid;
+ if (ctx)
+ audit_kill_uid = ctx->loginuid;
+ else
+ audit_kill_uid = current->uid;
+ }
+ }
+}
Any reason this should be unavailable when syscall auditing is off?
Perhaps it should be in audit core, and then make the pid/uid bits
static again.
+
diff -urB linux-2.6.9.orig/kernel/signal.c linux-2.6.9/kernel/signal.c
--- linux-2.6.9.orig/kernel/signal.c 2005-04-27 11:23:28.000000000 -0400
+++ linux-2.6.9/kernel/signal.c 2005-04-27 11:28:12.154629232 -0400
@@ -21,6 +21,7 @@
#include <linux/binfmts.h>
#include <linux/security.h>
#include <linux/ptrace.h>
+#include <linux/audit.h>
#include <asm/param.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -632,7 +633,11 @@
&& (current->uid ^ t->suid) && (current->uid ^ t->uid)
&& !capable(CAP_KILL))
return error;
- return security_task_kill(t, info, sig);
+
+ error = security_task_kill(t, info, sig);
+ if (!error)
+ audit_kill_info(sig, t); /* Let audit system see the signal */
+ return error;
}
/* forward decl */
diff -urB linux-2.6.9.orig/security/selinux/nlmsgtab.c
linux-2.6.9/security/selinux/nlmsgtab.c
--- linux-2.6.9.orig/security/selinux/nlmsgtab.c 2005-04-27 11:23:31.000000000 -0400
+++ linux-2.6.9/security/selinux/nlmsgtab.c 2005-04-27 11:22:51.000000000 -0400
@@ -97,6 +97,7 @@
{ AUDIT_WATCH_INS, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
{ AUDIT_WATCH_REM, NETLINK_AUDIT_SOCKET__NLMSG_WRITE },
{ AUDIT_WATCH_LIST, NETLINK_AUDIT_SOCKET__NLMSG_READPRIV },
+ { AUDIT_TERM_INFO, NETLINK_AUDIT_SOCKET__NLMSG_READ },
};
3:36 p.m.
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?
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.
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?
> @@ -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.
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.
Would some trivially simple sysfs file help you?
That depends on whether something is wrong above.
> @@ -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.
Thanks for looking this over.
-Steve
3:54 p.m.
On Wednesday 27 April 2005 16:36, Steve Grubb wrote:
> > + if (unlikely(audit_pid && t->pid ==
audit_pid)) {
> > + if (sig == SIGTERM || sig == SIGKILL) {
> Any reason this should be unavailable when syscall auditing is off?
I'm pretty sure I mis-read your question. Can you elaborate?
-Steve
4:56 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Wednesday 27 April 2005 16:36, Steve Grubb wrote:
> > > + if (unlikely(audit_pid && t->pid == audit_pid)) {
> > > + if (sig == SIGTERM || sig == SIGKILL) {
>
> > Any reason this should be unavailable when syscall auditing is off?
I'm pretty sure I mis-read your question. Can you elaborate?
That code is not compiled when CONFIG_AUDITSYSCALL=n. When I wrote that,
I didn't think syscall auditing would be requirement for this feature
(but, then again in that case the audit_context is non-existant, and
the loginuid is not there, and the whole point of this thing is perhaps
moot...)
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
5:08 p.m.
On Wednesday 27 April 2005 17:56, Chris Wright wrote:
That code is not compiled when CONFIG_AUDITSYSCALL=n. When I wrote
that,
I didn't think syscall auditing would be requirement for this feature
(but, then again in that case the audit_context is non-existant, and
the loginuid is not there, and the whole point of this thing is perhaps
moot...
That's about where I had gotten to in trying to figure out what you meant in
the first mail. Then I got to thinking that loginuid doesn't exist without
syscall auditing. I don't think that was ever thought of as we added
loginuid.
I can move the function prototype under CONFIG_AUDITSYSCALL. I think that's
the fix.
-Steve
4:46 p.m.
* 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
5:22 p.m.
On Wednesday 27 April 2005 17:46, Chris Wright wrote:
> What queue? audit_send_reply does a netlink unicast.
The socket buffer queue. The same one that's causing the problem right
now.
Then we have a bigger problem than this. Look at this code in audit.c:
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.
> 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?
Yes. I can look for well marked packets - its cheap. I cannot parse without
risk of clogging up the backlog and triggering a panic.
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()).
I would either need to examine each packet to see if its a TERM_INFO packet
and special handle that, or we'd have a race + compatibility issues. By
asking for the packet, the userspace tools are backwards compatible. You get
a netlink send error and the audit daemon goes ahead and shuts down. By
assuming the kernel will send one, we waiting for something that will never
come.
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.
-Steve
3:57 p.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Wednesday 27 April 2005 17:46, Chris Wright wrote:
> > What queue? audit_send_reply does a netlink unicast.
>
> The socket buffer queue. The same one that's causing the problem right
> now.
Then we have a bigger problem than this. Look at this code in audit.c:
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. 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.
> > 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?
Yes. I can look for well marked packets - its cheap. I cannot parse without
risk of clogging up the backlog and triggering a panic.
> 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()).
I would either need to examine each packet to see if its a TERM_INFO packet
and special handle that, or we'd have a race + compatibility issues. By
asking for the packet, the userspace tools are backwards compatible. You get
a netlink send error and the audit daemon goes ahead and shuts down. By
assuming the kernel will send one, we waiting for something that will never
come.
I see you point better now. You should never get the TERM_INFO payload
before the signal handler runs. But that doesn't handle backwards
compatibility. I hadn't even considered that was an issue here.
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?
thanks,
-chris
4:18 p.m.
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. 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.
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.
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. :\
> 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.
-Steve
4:25 p.m.
* Steve Grubb (sgrubb(a)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
10:52 a.m.
On Wednesday 27 April 2005 12:35, Steve Grubb wrote:
The attached patch addresses the problem with getting the audit
daemon
shutdown credential information. It creates a new message type
AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the
shutdown.
It requires the placement of a hook function that gathers the information.
The hook is after the DAC & MAC checks and before the function returns.
Racing threads could overwrite the uid & pid - but they would have to be
root and have policy that allows signalling the audit daemon. That should
be a manageable risk.
The userspace component will be released later in audit 0.7.2. When it
receives the TERM signal, it queries the kernel for shutdown information.
When it receives it, it writes the message and exits. The message looks
like this:
type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650
uid=525, auditd pid=1685
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
Attached is the revised patch with the audit_kill_info function prototype
moved up into the CONFIG_AUDITSYSCALL section of audit.h.
2:24 p.m.
New subject: [PATCH] Auditd shutdown credentials v3
On Thursday 28 April 2005 11:52, Steve Grubb wrote:
On Wednesday 27 April 2005 12:35, Steve Grubb wrote:
> The attached patch addresses the problem with getting the audit daemon
> shutdown credential information. It creates a new message type
> AUDIT_SIGNAL_INFO, which is used by the audit daemon to query who issued
> the shutdown or reload.
>
> It requires the placement of a hook function that gathers the
> information. The hook is after the DAC & MAC checks and before the
> function returns. Racing threads could overwrite the uid & pid - but they
> would have to be root and have policy that allows signalling the audit
> daemon. That should be a manageable risk.
>
> The userspace component will be released later in audit 0.7.2. When it
> receives the TERM signal, it queries the kernel for shutdown information.
> When it receives it, it writes the message and exits. The message looks
> like this:
>
> type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending
> pid=2650 uid=525, auditd pid=1685
>
> Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
Attached is the revised patch with the audit_kill_info function prototype
moved up into the CONFIG_AUDITSYSCALL section of audit.h.
This patch also hooks SIGHUP so that we can get the credentials of who
requested the audit daemon to be reloaded. Many things were renamed since
multiple signals are now hooked.
7492
days inactive
7494
days old
linux-audit@lists.linux-audit.osci.io
12 comments
2 participants
participants (2)
-
Chris Wright -
Steve Grubb