4:54 p.m.
Hello,
This is the discussion about meeting the CAPP requirement to log the real
user's ID that initiated a shutdown. The core issue is that shutdown sequence
is started by a SIGTERM. I can use sigaction to get some additional
information delivered to the signal handler. All you get is pid. It would be
racy to trace that back to the caller and see what their loginuid is.
Klaus proposed the following patch. Its an OK solution, but I was wanting to
see if there are alternatives. The problems I see is that this will always
require adding some rules, you will always have to start the audit daemon
from the init script to make sure the pid is captured, its racy on
termination - it waits a finite amount of time hoping the record makes it to
disk, people may accidentally delete the rule not knowing what it does,
there's a race getting the pid of the audit daemon - it forks starting up, it
slows down performance because it adds a another rule the audit system has to
evaluate each time there's a potential audit event, it occupies memory, etc.
Some other ideas I've pondered:
*adding user information to sigaction signal delivery
*having the kernel recognize kill to the audit daemon and auto generate an
event before delivering the signal
We need some ideas to pick the best way to solve the problem.
-Steve
---------- Forwarded Message ----------
Subject: Re: Fw: Audit records for start/stop auditd
Date: Thursday 17 March 2005 19:04
From: Klaus Weidner <klaus(a)atsec.com>
To: Kris Wilson <krisw(a)us.ibm.com>, Steve Grubb <sgrubb(a)redhat.com>
Hello,
I've worked around the problem in the following way - it's a bit of a
hack but I think easier than completely restructuring the code:
- dynamically add an audit rule from /etc/init.d/audit to monitor
signals sent to the auditd pid
- change auditd to keep processing kernel messages for two seconds
after getting the shutdown signal so that it has a chance to save
the "signal" event record.
This is what it looks like (i386, syscall 37 is "kill"):
type=KERNEL msg=audit(1111114589.580:4100282): syscall=37 exit=0
a0=469d a1=f a2=469d a3=469d items=0 pid=18094 loginuid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
type=DAEMON msg=auditd(1111114591) auditd normal halt, pid=18077, uid=0
I think this way the CAPP requirement is covered, even though it's not
pretty.
The patch contains one separate change - /etc/init.d/audit did not
actually reload the audit rules when run with the "reload" argument,
this caused me some head scratching while testing. The change adds the
reload.
-Klaus
On Thu, Mar 17, 2005 at 01:16:49PM -0600, Kris Wilson wrote:
What needs to be done? Here is the currrent record when auditd is
stopped:
type=DAEMON msg=auditd(1110848990) auditd normal halt, pid=12552, uid=0
----- Forwarded by Kris Wilson/Austin/IBM on 03/17/2005 01:14 PM -----
Steve Grubb
<sgrubb(a)redhat.co
m> To
Kris Wilson/Austin/IBM@IBMUS
03/17/2005 12:44 cc
PM
Subject
Re: Fw: Audit records for
start/stop auditd
On Thursday 17 March 2005 13:23, you wrote:
> Is there any way for the auditd stop record to include auid?
The shutdown comes from a signal. The sigaction call can send extra
information upon signal delivery. It has a field for the Real User ID.
However, the audit daemon runs as root, so only root can send it a signal.
So, I can go ahead and put root as the user that sent the shutdown
message...however, I can't get the loginuid. That's out of reach.
So, do you want me to "fake it" or leave it as is?
-Steve
-------------------------------------------------------
5:19 p.m.
On Tue, 2005-04-05 at 17:54 -0400, Steve Grubb wrote:
I've worked around the problem in the following way - it's a
bit of a
hack but I think easier than completely restructuring the code:
- dynamically add an audit rule from /etc/init.d/audit to monitor
signals sent to the auditd pid
- change auditd to keep processing kernel messages for two seconds
after getting the shutdown signal so that it has a chance to save
the "signal" event record.
This is what it looks like (i386, syscall 37 is "kill"):
type=KERNEL msg=audit(1111114589.580:4100282): syscall=37 exit=0
a0=469d a1=f a2=469d a3=469d items=0 pid=18094 loginuid=500 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
Chris and I looked at this and discussed the possibility of adding a
check in security_task_kill() -- or we could at least add a new
audit_task_kill() next to it in signal.c::check_kill_permission().
That would be an inline function which checks for t->pid == audit_pid
and either marks the syscall auditable or just logs an appropriate
report.
--
dwmw2
8:59 a.m.
On Tuesday 05 April 2005 18:19, David Woodhouse wrote:
Chris and I looked at this and discussed the possibility of adding a
check in security_task_kill()
Out of curiosity, what about the possibility of augmenting siginfo_t?
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void * si_ptr; /* POSIX.1b signal */
void * si_addr; /* Memory location which caused fault */
int si_band; /* Band event */
int si_fd; /* File descriptor */
uid_t si_luid /* Login uid */
}
This is actually the cleanest way for the audit daemon. No races, no hanging
around waiting for a message that may never come.
-Steve
8:57 a.m.
On Wed, 2005-04-06 at 09:59 -0400, Steve Grubb wrote:
Out of curiosity, what about the possibility of augmenting siginfo_t?
siginfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
int si_status; /* Exit value or signal */
clock_t si_utime; /* User time consumed */
clock_t si_stime; /* System time consumed */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void * si_ptr; /* POSIX.1b signal */
void * si_addr; /* Memory location which caused fault */
int si_band; /* Band event */
int si_fd; /* File descriptor */
uid_t si_luid /* Login uid */
}
This is actually the cleanest way for the audit daemon. No races, no hanging
around waiting for a message that may never come.
Won't that break the kernel ABI?
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
9:09 a.m.
On Wednesday 06 April 2005 09:57, Stephen Smalley wrote:
Won't that break the kernel ABI?
I put it at the end so apps that have already been compiled with the old
siginfo_t size won't break. The app is handed a pointer to the structure by
the kernel, so its not like userspace ever allocates the struct, it just
references the contents of it.
-Steve
9:04 a.m.
On Wed, 2005-04-06 at 10:09 -0400, Steve Grubb wrote:
On Wednesday 06 April 2005 09:57, Stephen Smalley wrote:
> Won't that break the kernel ABI?
I put it at the end so apps that have already been compiled with the old
siginfo_t size won't break. The app is handed a pointer to the structure by
the kernel, so its not like userspace ever allocates the struct, it just
references the contents of it.
I think that the kernel _copies_ the structure to userspace (using a
pointer provided by userspace), so extending it will cause clobbering of
memory for any application that was built with the old structure. See
copy_siginfo_to_user in kernel/signal.c.
--
Stephen Smalley <sds(a)tycho.nsa.gov>
National Security Agency
9:09 a.m.
On Wed, 2005-04-06 at 10:09 -0400, Steve Grubb wrote:
I put it at the end so apps that have already been compiled with the
old
siginfo_t size won't break. The app is handed a pointer to the structure by
the kernel, so its not like userspace ever allocates the struct, it just
references the contents of it.
Stack unwinders need to step over it -- it can't grow either.
--
dwmw2
9:06 a.m.
On Wednesday 06 April 2005 09:59, Steve Grubb wrote:
This is actually the cleanest way for the audit daemon. No races, no
hanging around waiting for a message that may never come.
On second thought, what if they send a SIGKILL? Maybe we need Dave's original
patch and this?
-Steve
9:14 a.m.
* Steve Grubb (sgrubb(a)redhat.com) wrote:
On Tuesday 05 April 2005 18:19, David Woodhouse wrote:
> Chris and I looked at this and discussed the possibility of adding a
> check in security_task_kill()
Out of curiosity, what about the possibility of augmenting siginfo_t?
There's no guarantee that siginfo will be delivered (it's not required
for non-realtime signals).
thanks,
-chris
9:21 a.m.
On Wednesday 06 April 2005 09:59, Steve Grubb wrote:
> Chris and I looked at this and discussed the possibility of
adding a
> check in security_task_kill()
OK, extending siginfo_t might be problematic. What about adding SA_AUDITINFO
to sigaction?
sigauditinfo_t {
int si_signo; /* Signal number */
int si_errno; /* An errno value */
int si_code; /* Signal code */
pid_t si_pid; /* Sending process ID */
uid_t si_uid; /* Real user ID of sending process */
uid_t si_luid /* Login ID of sending process */
int si_status; /* Exit value or signal */
sigval_t si_value; /* Signal value */
int si_int; /* POSIX.1b signal */
void * si_ptr; /* POSIX.1b signal */
}
Maybe other things for lspp/selinux, too?
-Steve
8:25 a.m.
On Tue, 2005-04-05 at 17:54 -0400, Steve Grubb wrote:
This is the discussion about meeting the CAPP requirement to log the
real
user's ID that initiated a shutdown. The core issue is that shutdown sequence
is started by a SIGTERM. I can use sigaction to get some additional
information delivered to the signal handler. All you get is pid. It would be
racy to trace that back to the caller and see what their loginuid is.
Klaus proposed the following patch. Its an OK solution, but I was wanting to
see if there are alternatives.
How about this? You can replace (or augment) the audit_log() with a
printk() if you need to, but if you're shutting down gracefully due to
SIGTERM you'll catch the message anyway, right?
--- linux-2.6.9/kernel/audit.c.p20019 2005-04-06 13:06:39.000000000 +0100
+++ linux-2.6.9/kernel/audit.c 2005-04-06 13:06:39.000000000 +0100
@@ -68,7 +68,7 @@ static int audit_failure = AUDIT_FAIL_PR
/* 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
--- linux-2.6.9/kernel/signal.c.p20019 2005-04-06 13:06:39.000000000 +0100
+++ linux-2.6.9/kernel/signal.c 2005-04-06 13:07:29.000000000 +0100
@@ -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>
@@ -623,7 +624,7 @@ static int check_kill_permission(int sig
int error = -EINVAL;
if (sig < 0 || sig > _NSIG)
return error;
- error = -EPERM;
+
if ((!info || ((unsigned long)info != 1 &&
(unsigned long)info != 2 && SI_FROMUSER(info)))
&& ((sig != SIGCONT) ||
@@ -631,8 +632,12 @@ static int check_kill_permission(int sig
&& (current->euid ^ t->suid) && (current->euid ^
t->uid)
&& (current->uid ^ t->suid) && (current->uid ^ t->uid)
&& !capable(CAP_KILL))
- return error;
- return security_task_kill(t, info, sig);
+ error = -EPERM;
+ else
+ error = security_task_kill(t, info, sig);
+
+ audit_kill_permission(sig, info, t, error);
+ return error;
}
/* forward decl */
--- linux-2.6.9/include/linux/audit.h.p20019 2005-04-06 13:06:39.000000000 +0100
+++ linux-2.6.9/include/linux/audit.h 2005-04-06 13:06:39.000000000 +0100
@@ -234,6 +234,15 @@ extern void audit_send_reply(int pi
int done, int multi,
void *payload, int size);
extern void audit_log_lost(const char *message);
+static inline void audit_kill_permission(int sig, struct siginfo *info,
+ struct task_struct *t, int err)
+{
+ extern int audit_pid; /* Nothing external _except_ for this should use it */
+
+ if (unlikely(t->pid == audit_pid))
+ audit_log(NULL, "attempt to signal audit daemon: error=%d signal=%d pid=%d
auid=%d",
+ err, sig, current->pid, audit_get_loginuid(current->audit_context));
+}
#else
#define audit_log(t,f,...) do { ; } while (0)
#define audit_log_start(t) ({ NULL; })
@@ -249,6 +258,7 @@ extern void audit_log_lost(const ch
#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_permission(s,i,t,e) do { ; } while (0)
#endif
#endif
#endif
--
dwmw2
8:54 a.m.
On Wednesday 06 April 2005 09:25, David Woodhouse wrote:
+static inline void audit_kill_permission(int sig, struct siginfo
*info,
+ struct task_struct *t, int err)
+{
+ extern int audit_pid; /* Nothing external _except_ for this should
use it */ +
+ if (unlikely(t->pid == audit_pid))
+ audit_log(NULL, "attempt to signal audit daemon: error=%d
signal=%d pid=%d auid=%d", + err, sig,
current->pid, audit_get_loginuid(current->audit_context)); +}
I wonder if we should have another audit message type AUDIT_TERM. Then in the
above function, do an if statement on SIGTERM or SIGKILL and send the
AUDIT_TERM message type. The message needs to be easily interpreted as the
audit system is being terminated. Then we could have an else statement that
uses the audit log like you have above. Maybe something like:
static inline void audit_kill_permission(int sig, struct siginfo *info,
struct task_struct *t, int err)
{
extern int audit_pid; /* Nothing external _except_ for this should use
it */
if (unlikely(t->pid == audit_pid)) {
if (sig == SIGTERM || sig == SIGKILL) {
struct audit_buffer *ab;
ab = audit_log_start(NULL);
if (ab) {
audit_log_format(ab,
"signal=%d pid=%d loginuid=%d'",
sig, pid,
audit_get_loginuid(current->audit_context),
ab->type = AUDIT_TERM;
ab->pid = pid;
audit_log_end(ab);
} else
printk("attempt to signal audit daemon: error=%d signal=%d pid=%d
auid=%d",
err, sig, current->pid, audit_get_loginuid(current->audit_context));
} else {
audit_log(NULL,
"attempt to signal audit daemon: error=%d signal=%d pid=%d loginuid=%d",
err, sig, current->pid, audit_get_loginuid(current->audit_context));
}
}
}
Of course, if we introduce and AUDIT_TERM message type, we should have a
AUDIT_START message type just for symmetry.
-Steve
9:50 a.m.
linux-audit-bounces(a)redhat.com wrote on 04/06/2005 08:54:10 AM:
I wonder if we should have another audit message type AUDIT_TERM.
Then in
the
above function, do an if statement on SIGTERM or SIGKILL and send
the
AUDIT_TERM message type. The message needs to be easily interpreted as
the
audit system is being terminated.
The current records are type DAEMON, and the messages state, "auditd start"
and "auditd normal halt", so as far as administrator information, it is
already clear what has happened.
10:21 a.m.
On Wednesday 06 April 2005 10:50, Kris Wilson wrote:
The current records are type DAEMON, and the messages state,
"auditd start"
and "auditd normal halt", so as far as administrator information, it is
already clear what has happened.
I was thinking about exiting as soon as I see the message come though or a
timeout - whichever comes first. However, I cannot parse the messages since
we need to write them as fast as possible. By having another message type, I
can do this.
But this is completely avoided if I can get the information when the signal is
delivered.
BTW, If I send a SIGKILL to the audit daemon - it gets yanked out of memory by
the kernel without any courtesy. I wonder how this was covered by laus or is
this considered outside the bounds of what is reasonable? Same thing with a
user shell, there won't be a pam_close_session call.
For LSPP are there additional requirements that we should consider now so that
this doesn't come up "next time"?
-Steve
12:10 p.m.
On Wed, Apr 06, 2005 at 11:21:26AM -0400, Steve Grubb wrote:
BTW, If I send a SIGKILL to the audit daemon - it gets yanked out of
memory by
the kernel without any courtesy. I wonder how this was covered by laus or is
this considered outside the bounds of what is reasonable? Same thing with a
user shell, there won't be a pam_close_session call.
Sending SIGKILL auditd needs administrator privileges, and for CAPP we
can assume/require them not to do that.
The pam_close_session record isn't required by CAPP, we had a discussion
about session end records some time ago. It's generally less reliable
than the start record anyway since the session close record doesn't mean
that all processes launched by that user have terminated; some may have
been backgrounded.
For LSPP are there additional requirements that we should consider
now so that
this doesn't come up "next time"?
LSPP has essentially the same audit requirements as CAPP, it only adds
requirements for new fields related to the "sensitivity labels of
subjects, objects, or information involved".
-Klaus
4:11 p.m.
On Fri, 2005-04-08 at 12:10 -0500, Klaus Weidner wrote:
Sending SIGKILL auditd needs administrator privileges, and for CAPP
we
can assume/require them not to do that.
The pam_close_session record isn't required by CAPP, we had a discussion
about session end records some time ago. It's generally less reliable
than the start record anyway since the session close record doesn't mean
that all processes launched by that user have terminated; some may have
been backgrounded.
One answer to this might be to assign a unique 'session id' cookie at
login time, then store and log it with the loginuid at all times.
Going back to the issue of auditd shutdown, however -- are we satisfied
with merely generating records when the audit_pid is signalled, or
should I revert that patch while we seek a better solution?
--
dwmw2
5:12 p.m.
On Friday 08 April 2005 17:11, David Woodhouse wrote:
Going back to the issue of auditd shutdown, however -- are we
satisfied
with merely generating records when the audit_pid is signalled, or
should I revert that patch while we seek a better solution?
I've never seen kernel 19 log the signal.
We are going to have the exact same problem when we ad the code for LSPP. I'd
like to have a solution lined up so we done face the same problem. When we
start making the LSPP capable, we will need to record the SE Linux label for
the user that sent the signal.
What we could do is perform a switcheroo in the kernel. If a signal is
permitted to be sent to the audit daemon, put the loginuid into the si_uid
filed of siginfo_t. si_uid will always be 0, so why not overwrite it with
something meaningful? Next question would be what field could we use for the
SE Linux context?
Otherwise, I think a SA_AUDITINFO sigaction flag would be cleanest. Basically,
if we set that flag, it still uses the same function signature:
void (*sa_sigaction)(int, siginfo_t *, void *);
But we would use a different structure to access the contents of the siginfo_t
pointer. As far as I know, we only need 3-4 fields, so its smaller than
siginfo_t.
-Steve
1:58 p.m.
On Fri, 2005-04-08 at 18:12 -0400, Steve Grubb wrote:
On Friday 08 April 2005 17:11, David Woodhouse wrote:
> Going back to the issue of auditd shutdown, however -- are we satisfied
> with merely generating records when the audit_pid is signalled, or
> should I revert that patch while we seek a better solution?
I've never seen kernel 19 log the signal.
I've now set up an i686 box too, and I'm definitely seeing the signal
get logged correctly there too. In audit.27 (which is currently
building) I've added a printk as well, so we'll know for sure that the
message is being generated. I suspect you're just seeing that auditd is
dropping the message before it shuts down.
type=KERNEL msg=audit(1114795432.814:0): attempt to signal audit daemon: error=0
signal=15 pid=4068 auid=-1
type=DAEMON msg=auditd(1114795432) auditd normal halt, pid=4059, uid=0
--
dwmw2
2:29 p.m.
On Friday 29 April 2005 14:58, David Woodhouse wrote:
I suspect you're just seeing that auditd is
dropping the message before it shuts down.
That whole scheme is too racy. The signal patch I sent works everytime. Chris
has mentioned the possibility of netlink_unicast being a problem and I think
that's the only problem left outstanding. That problem should be solved
separately from the signal patch since its a generic problem with the audit
netlink code.
-Steve
5:23 p.m.
On Fri, Apr 08, 2005 at 10:11:34PM +0100, David Woodhouse wrote:
On Fri, 2005-04-08 at 12:10 -0500, Klaus Weidner wrote:
> The pam_close_session record isn't required by CAPP, we had a discussion
> about session end records some time ago. It's generally less reliable
> than the start record anyway since the session close record doesn't mean
> that all processes launched by that user have terminated; some may have
> been backgrounded.
One answer to this might be to assign a unique 'session id' cookie at
login time, then store and log it with the loginuid at all times.
That's what the LAuS implementation did - it's not strictly CAPP required
but it's helpful for tracing back an arbitrary audit event record to the
corresponding login record that started the session.
It's in theory possible to do that without a session ID by tracing the
ancestry through records of fork() syscalls, but that's a lot more work
and needs an uninterrupted audit trail of all intervening fork()s.
-Klaus
7177
days inactive
7201
days old
linux-audit@lists.linux-audit.osci.io
19 comments
6 participants
participants (6)
-
Chris Wright -
David Woodhouse -
Klaus Weidner -
Kris Wilson -
Stephen Smalley -
Steve Grubb