[PATCH] Audit capabilities
by Serge Hallyn
Attached is a new patch to introduce CAP_AUDIT_CONTROL and
CAP_AUDIT_WRITE. Thank you all for the clarifications on appropriate
caps.
Purpose: Audit message authentication is being done on the process
receiving the message, which may not be the process sending the message.
This patch sets the sk_buff eff_caps according to the sender
permissions, and authenticates audit message handling based on that. It
also switches from using CAP_SYS_ADMIN to using AUDIT capabilities.
Changelog:
12-20-2005: Switch from CAP_[SYS,NET]_ADMIN to AUDIT capabilities.
12-27-2005: Use dummy_capget in dummy_netlink_send, and correctly mask
the skb's eff_cap according to selinux perms.
12-28-2005: Use avc_has_perm_noaudit in selinux_netlink_send to use
cached decisions.
01-06-2005: Switch to using CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE.
thanks,
-serge
--
Serge Hallyn <serue(a)us.ibm.com>
21 years, 1 month
auditd design decision
by Timothy R. Chavez
Hello,
I've been mucking around with libaudit.c and auditctl.c to add the
ability to insert watch points into the filesystem via the auditctl
command line interface. But last night in a dream, a giant donut told
me that I should just create a file, watch.list, which auditd will
read when its started and insert any/all new watches into the
filesystem. This way, when we mount over /etc, and we're watching
/etc/passwd, then when we restart auditd, /etc it will insert a watch
for /etc/passwd on the new device. We do it this way so we minimize
our impact on kernel code (not sure we want to go screwing around with
mount()) This might be a little cumbersome to do when we wish to
remove watch points, because in theory, we'd want to detect the
absence of /etc/passwd on a restart to know that we must remove its
watch point from the file system. Does this sound reasonable or do we
need a greater degree of flexibility with the ability to insert/remove
watch points without restarting auditd like we do with rules?
--
- Timothy R. Chavez
21 years, 1 month
RE: audit 0.6 release
by Browder, Tom
I appreciate all the helpful comments on my look at auditd.
To see what I can do now with audit 0.6, I tried one rule similar to
requirements I've mentioned, one failed attempt to trigger an auditd
response, and looked at the output to see the feasibility of filtering
the output:
Using audit-0.6, my single rule is (from /sbin/audtctl -l):
AUDIT_LIST: exit always uid=507 (0x1fb) syscall=unlink
The failed attempt to be logged was:
% rm /etc/passwd
The two messages generated in audit.log were:
type=KERNEL msg=audit(1105106227.435:12373636): item=0 name=/etc/passwd
\
inode=5079041 dev=00:00-l inode=3080372 dev=00:00loginuid=-1 \
uid=507 gid=503 euid=507 suid=507 fsuid=507 egid=503 sgid=503
fsgid=50333gid=503
type=KERNEL msg=audit(1105106227.435:12373636): syscall=10
exit=4294967283 \
a0=bff86b22 a1=0 a2=80505e4 a3=bff86b22 items=1 pid=6137 loginuid=-1 \
uid=507 gid=503 euid=507 suid=507 fsuid=507 egid=503 sgid=503
fsgid=503503
Notice that I can get the file name, the system call, and the exit
status of
unlink (but I suspect the print format for the exit code is %u instead
of %d,
thus the apparent large number probably from a negative exit code).
But do there have to be two messages? Having one would enable easy
querying
(assuming I can parse on exit != 0), otherwise a little more difficult
(can I assume the messages always come in matching, adjacent pairs?).
To sum up, I believe I can write a perl parser to do what I need now
(assuming the exit code is correct), even though the message traffic is
so high. As autitd's rule capability gets more sophisticated, the
message traffic should decrease immensely.
I also will write a perl script to perform as my manual rule loader
until auditd has its own.
Thanks.
-Tom Browder
21 years, 1 month
auditd 0.6.1 released
by Steve Grubb
Hi,
Just wanted to let everyone know that a new version of the audit daemon has
been released. You can download tarball & srpm from
http://people.redhat.com/sgrubb/audit It will also be available in rawhide
tomorrow morning.
This release features a big cleanup of the auditctl code. I have new man pages
for it that hopefully makes life easier for people.
This release also features a new config option admin_space_left &
admin_space_left_action. This is meant to be the soft limit where you can
configure the system to go into single user mode. It should still leave a
configurable amount of space left for logging anything that occurs while
freeing up disk space or before you hit the hard limit. There's a few more
cleanups in the documentation and code.
Still not quite ready for beta testing but a little closer...
-Steve Grubb
21 years, 1 month
RE: audit 0.6 release
by Browder, Tom
I have a working (but rough) perl script and accompanying module that
will do the following:
1. delete all existing rules shown by '/sbin/auditctl -a'
Given a list of user names, directories of interest, and system call
names:
2. add rules to report all exit!= 0 for all calls and user names of
interest
3. run a query on an audit log and spit out info on lines of interest
Given the present state of auditd messages this is the best I can come
up with for now. I think it is easiy modifiable for those interested.
One thing I know it needs now is a list of specific return codes of
interest for the query.
By the way, I see that there are not always pairs of messages. If a
syscall has at least one accompanying message it has 'items=1' (or more
sometimes I guess). So while querying I check for that and look behind
one line for additional info if appropriate. There may be other gotchas
I gain more experience sifting through the log.
Let me know if you want a copy.
-Tom Browder
21 years, 1 month
RE: audit 0.6 release
by Browder, Tom
On the TODO list you might add a way to delete all rules with auditctl
(maybe a -D switch?).
The current removal method, rule by rule, is awkward and error-prone due
to the format of output using the -l switch.
(I hope I didn't miss something in a man page).
-Tom Browder
21 years, 1 month
RE: audit 0.6 release
by Browder, Tom
> -----Original Message-----
> From: linux-audit-bounces(a)redhat.com
> [mailto:linux-audit-bounces@redhat.com] On Behalf Of
> Valdis.Kletnieks(a)vt.edu
> Sent: Thursday, January 06, 2005 4:17 PM
> To: Linux Audit Discussion
> Subject: Re: audit 0.6 release
> logrotate doesn't do a very good job of handling "roll to
> next file when this one is 40M in size", because the cron job
> is probably not running at the time that the log gets to 40M.
> The semantics of "rotate at 2AM if it's over 40M then" are
> quite different from "rotate at current clocktime 11:37AM if
> we hit 40M then...".
>
> Also, in a priv-separated environment, only the "security
> officer" role should be allowed to remove an audit file
> (while logrotate's "rotate" command will rm the oldest one
> if/when needed). So you probably need to use *two* logrotate
Instead of the logrotate methodology, how about letting auditd do it.
For my purposes I would like to see the audit logs saved as something
like 'audit.log.2004m12hd01h0001s00CST_2004m12d04h1231s42CST' (and g or
bzipped). So the auditd could save the time stamp of the last log save,
and when full or at the next user desired time, atomically save the
existing log and start a new one without missing a message (then start a
backgound zip job for the saved log).
Tom Browder
21 years, 1 month
[RFC][PATCH] Inherit loginuid from parent
by Stephen Smalley
Hi,
I might be mis-reading the code, but it appears that the current
audit_alloc() code is not preserving the loginuid of the parent process
for the child process upon a fork or clone. Instead, it is checking to
see if the just-created child has an existing audit context and if so,
copies the loginuid from it, which seems nonsensical, especially as it
does nothing to free any existing audit context if one exists already.
Does this patch look correct? In this context, tsk == the child, and
current == the parent. The child has not yet started execution at this
point; it is still being setup by the fork/clone code.
--- linux-2.6.10/kernel/auditsc.c.orig 2005-01-06 13:11:51.000000000 -0500
+++ linux-2.6.10/kernel/auditsc.c 2005-01-06 13:14:28.000000000 -0500
@@ -549,8 +549,8 @@ int audit_alloc(struct task_struct *tsk)
/* Preserve login uid */
context->loginuid = -1;
- if (tsk->audit_context)
- context->loginuid = tsk->audit_context->loginuid;
+ if (current->audit_context)
+ context->loginuid = current->audit_context->loginuid;
tsk->audit_context = context;
set_tsk_thread_flag(tsk, TIF_SYSCALL_AUDIT);
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
21 years, 1 month
Handling disk full & No Kernel resources
by Mounir Bsaibes
I want to reactivate this thread of discussion to come to a closure on
this subject and implement the solution as fast as possible.
First, I will summarize what we are trying to do. Then I will state
where we left off, I will restate the original proposal and the responses
to the original proposal. Finally, I will provide another proposal to
start the discussion. This is a long note.
The Background
One of the CAPP requirements and probably the LSPP as well is when audit
records cannot be generated, for a particular process, the process need to
be halted. We are considering 2 separate cases when the audit records
cannot be generated.
1) The first, is when the audit log is full and the audit subsystem cannot
write the audit record.
2) The second, is when the kernel cannot allocate memory to generate the
audit buffer.
One of the reasons these 2 cases are treated separately is because for the
first case (disk full), the audit subsystem can know ahead of time that
the audit record cannot be written out to disk (auditd can for example
send a message informing the audit system of this situation). So, the
audit subsystem has the ability to suspend the process (or all the
processes) before they perform auditable action(s). In contrast, for the
second case (no kernel resources) the audit subsystem cannot know ahead of
time that the kernel resources are exhausted. It is only, when the audit
subsystem is trying to generate the audit record, when it discovers that
no resources are available. The auditable action already took place.
The Initial proposal
1) For handling disk full:
Whenever the disk full (or log reached its limit) is detected the
auditd sends an AUDIT_SUSPEND message to the kernel. On receipt of
this message the kernel will set a flag "disk_full_flag". If this
disk_full_flag is set audit_log_start will call audit_suspend to
queue the process in a wait queue. Whenever the disk_full_flag is
reset all the processes in the wait queue will be rescheduled.
2) For suspending the process whenever there are no kernel resources:
I was thinking of using sigsuspend whenever audit_log_lost is called
depending on the "failure flag". The failure flag currently can be set
only, to: i) do nothing, ii) print a message or iii) panic. I was
thinking of
adding a fourth option to this flag to suspend the processes.
Responses to the initial proposal
1) Should not change the audit_log* functions because they can be called
from different context(Chris White).
This can only safely be done from either:
a) audit_syscall_exit, or
b) some new audit_log* functions that are explicitly identified as
potentially blocking.
(Stephen Smalley)
2) Sigsuspend is not safe (Stephan Smalley).
There may not be any local process associated with the event, e.g.
SELinux can generate audit data during processing of received packets.
the processing you describe can only safely be done from either:
a) audit_syscall_exit, or
b) some new audit_log* functions that are explicitly identified as
potentially blocking.
Current proposal
1) For handling disk full:
Instead of calling the audit_suspend from audit_log_start. I will call it
from audit_syscall_entry
if the context is auditable. audit_suspend will place the process in a
wait_queue until the disk_full_flag is reset. At that time all the
processes in the wait queue will be awakened.
Hopefully this is acceptable and I can go ahead and implement this.
The question is how SELinux should treat its audit records in this case?
For the current CAPP work this is not an issue. However, it will be for
LSPP evaluation.
2) For suspending the process whenever there are no kernel resources:
Audit_log_lost is called from many places for many reasons no memory,
socket is busy, etc.. I need to think a little bit more about this. If we
don't want to sleep in any audit_log* function. Any suggestion?
Mounir Bsaibes
Linux Security
Tel: (512) 838-1301
Cell: (512) 762-9957
Fax: (512) 838-8858
e-mail: bsaibes(a)us.ibm.com
21 years, 1 month
Two netlink patches
by Serge Hallyn
Hi,
Is there any objection to my sending the two netlink patches I recently
sent out to lkml? Just to refresh memory, the one (audit-fix-
permchecks.diff) adds some message length checks and moves audit control
message authorization to netlink message send, while the other (audit-
loginuid.patch) changes the SET_LOGINUID behavior to set loginuid for
the sending process (as expected) rather than whichever process happens
to end up handling the message.
thanks,
-serge
--
Serge Hallyn <serue(a)us.ibm.com>
21 years, 1 month
