rotating audit logs
by Bill Tangren
I am required to rotate the audit logs daily on my RHEL boxes. As far as I can
tell from the auditd.conf file, the auditd daemon only rotates the files when
max_log_file reaches a certain size.
Is is possible to have the auditd daemon rotate the logs according to time,
rather than size?
If auditd cannot do this, is it possible to turn off log rotating and let the
logrotate daemon do it?
Thanks,
Bill Tangren
19 years, 1 month
Re: [RFC] security_getprocattr() API idiocy
by Stephen Smalley
On Tue, 2007-02-13 at 13:45 +0000, Al Viro wrote:
> security_getprocattr() takes a buffer + length, copies data
> to it and return the actual length. If buffer is NULL, it just returns
> the right length, a-la snprintf(). Observations:
> * at least selinux ends up actually allocating the buffer of the
> right size, filling it, then copying its contents to buffer and freeing
> what had been allocating.
> * all users allocate buffer, then call security_getprocattr() to
> fill just allocated one.
> * one place does even worse - it calls security_getprocattr() passing
> it NULL and uses obtained length to allocate buffer and call
> security_getprocattr() _again_.
>
> It's bloody bogus. In all cases we would be just as happy if it returned
> the buffer it'd allocated itself. In the best case we end up with two
> allocations; in the worst it's _three_, not to mention recalculating the
> contents and size. We end up doing
> * calculate size
> * allocate buffer of that size with GFP_ATOMIC
> * fill it
> * free it
> * allocate buffer of that size with GFP_KERNEL
> * caluclate the same size
> * allocate buffer of that size with GFP_ATOMIC
> * fill it with the same string
> * copy it to buffer we's allocated with GFP_KERNEL
> * free the buffer we'd allocated with GFP_ATOMIC
> I'm sorry, but could we please not mix the kernel with Vogon poetry contest?
>
> AFAICS, the sane solution is to make security_getprocattr() return the
> allocated buffer instead. All callers would be only happy with that.
> Alternatively, we can introduce a new LSM hook (security_getprocattr_sane())
> and leave the original as-is.
>
> So, do we want to keep the original variant and add a saner one in parallel
> to it or should we just switch to saner API?
Just switch to the saner API.
audit_log_task_context) could be using selinux_get_task_sid() +
selinux_sid_to_string() instead of security_getprocattr.
--
Stephen Smalley
National Security Agency
19 years, 1 month
RHELU4 versus RHELU5
by Kirkwood, David A.
I have not looked at the audit capability on RHELU5, but from the mail
on this list I get a sense that it is, from the configuration and review
tools significantly different that used in the previous release. First,
Is this a correct assumption? I need to get approval to use systems and
verify audit capabilities for those systems, but I don't want to have to
go through the whole thing all over again.
Thanks,
David A. Kirkwood
SAIC
david.a.kirkwood(a)saic.com
kirkwoodd(a)saic.com
Phone: (727) 502-8310
Fax: (727) 822-7776
19 years, 1 month
proc_loginuid_write() checks wrong capability?
by Steve Beattie
Hi,
Looking at the code for proc_loginuid_write() in Linus' git tree, the
capability CAP_AUDIT_CONTROL is needed to write to /proc/pid/loginuid
and generate LOGIN type records. This seems to run counter to the
capabilities(7) manpage, which suggests that CAP_AUDIT_CONTROL is to
"Enable and disable kernel auditing; change auditing filter rules;
retrieve auditing status and filtering rules", whereas CAP_AUDIT_WRITE
is to "Allow records to be written to kernel auditing log."
Should the following patch be applied, or am I misunderstanding
something? It doesn't seem quite right that anything that makes use of
pam_loginuid.so should need to be granted the capability that allows
enabling and disabling kernel auditing or changing filter rules.
Signed-off-by: Steve Beattie <sbeattie(a)suse.de>
---
fs/proc/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kernel-linus/fs/proc/base.c
===================================================================
--- kernel-linus.orig/fs/proc/base.c
+++ kernel-linus/fs/proc/base.c
@@ -741,7 +741,7 @@ static ssize_t proc_loginuid_write(struc
ssize_t length;
uid_t loginuid;
- if (!capable(CAP_AUDIT_CONTROL))
+ if (!capable(CAP_AUDIT_WRITE))
return -EPERM;
if (current != pid_task(proc_pid(inode), PIDTYPE_PID))
Thanks.
--
Steve Beattie
SUSE Labs, Novell Inc.
<sbeattie(a)suse.de>
http://NxNW.org/~steve/
19 years, 1 month
RHEL4 panic when renaming with a watched file as the target
by Eric Paris
Since the upstream filesystem auditing is different than RHEL4 this
problem (I believe) is RHEL4 specific. Lets assume I add the rule
auditctl -w /tmp/watched_file
then I run
touch /tmp/unwatched_file
mv -f /tmp/watched_file
For the purposes of this discussion lets call the inode for the
original /tmp/watched_file i1 and the indoe for the
original /tmp/unwatched_fiel i2.
The RHEL4 kernel panics. The reason is because it wants to allocate a
audit_inode_data to i2 but there is no audit_inode_data to allocate.
Thus we get the panic as seen in RH BZ 223129.
When the watch was originally inserted the kernel mallocs 2
audit_inode_data structs. One for the inode to be watched and one for
the parent of the that inode. In our case the panic happens because
those 2 structs are allocated for i1 and for the inode associated
with /tmp. From looking at the code I saw that in d_move we were
dropping the audit_inode_data associated with i2 (inside that function
i2 is pointed at by "dentry") at the beginning. But we were not
dropping the watch on i1. It appears that the watch was intended to
have been dropped on i1 later in i_put. At the end of d_move we add the
watch for i2. It was at this point that things blew up (as i_put had
not yet released the data structure.)
My first attempt at fixing this simply was to change d_move such that it
would drop the audit_inode_data for both i1 and i2 and then add it back
to i2 once i2 was the inode which needed the watch. This however simply
moved the panic into i_put when it wanted to remove the audit_inode_data
from the original i1. The reason it panics there is because when trying
to fetch the audit_inode_data to free it, it was actually trying to
allocate a new struct so it had something to free! My solution simply
passes a new flag to audit_data_get which states if the intent of
requesting the audit_inode_data is to use it or to remove it. If the
intent of getting the audit_inode_data was to simply remove that struct
from the inode there is no need to allocate a new one just to have it
removed.
This patch appears to fix the panic and to correctly watch the correct
inodes at the correct times. I'd love comment as there may be other
solutions to either of the problems. Maybe we like the removal of the
watch on i1 in d_move but we don't like the new flags. In that case we
could just 'mess' around with i1 at the end of d_move such that it
wouldn't watch the watch in i_put and wouldn't ever get into
audit_data_get to cause the secondary panic. Maybe there is something
I'm missing altogether. Anyway comments please before I put this into a
RHEL4 kernel would be appreciated.
-Eric
diff -Naupr linux-2.6.9/fs/dcache.c linux-2.6.9/fs/dcache.c
--- linux-2.6.9/fs/dcache.c 2007-02-05 13:12:01.000000000 -0500
+++ linux-2.6.9/fs/dcache.c 2007-02-05 13:09:36.000000000 -0500
@@ -1292,6 +1292,7 @@ void d_move(struct dentry * dentry, stru
}
audit_update_watch(dentry, 1);
+ audit_update_watch(target, 1);
/* Move the dentry to the target hash queue, if on different bucket */
if (dentry->d_flags & DCACHE_UNHASHED)
diff -Naupr linux-2.6.9/kernel/auditfs.c linux-2.6.9/kernel/auditfs.c
--- linux-2.6.9/kernel/auditfs.c 2007-02-05 13:11:49.000000000 -0500
+++ linux-2.6.9/kernel/auditfs.c 2007-02-05 13:09:09.000000000 -0500
@@ -110,7 +110,8 @@ static void audit_data_pool_shrink(void)
spin_unlock(&auditfs_hash_lock);
}
-static struct audit_inode_data *audit_data_get(struct inode *inode, int allocate)
+static struct audit_inode_data *audit_data_get(struct inode *inode, int allocate,
+ int remove)
{
struct audit_inode_data **list;
struct audit_inode_data *ret = NULL;
@@ -142,7 +143,7 @@ static struct audit_inode_data *audit_da
if (ret) {
ret->count++;
- } else if (allocate) {
+ } else if (allocate && !remove) {
ret = audit_data_pool;
audit_data_pool = ret->next_hash;
audit_pool_size--;
@@ -410,7 +411,7 @@ static inline int audit_insert_watch(str
if (nd.last_type != LAST_NORM || !nd.last.name)
goto release;
- pdata = audit_data_get(nd.dentry->d_inode, 1);
+ pdata = audit_data_get(nd.dentry->d_inode, 1, 0);
if (!pdata)
goto put_pdata;
@@ -478,7 +479,7 @@ static inline int audit_remove_watch(str
if (nd.last_type != LAST_NORM || !nd.last.name)
goto audit_remove_watch_release;
- data = audit_data_get(nd.dentry->d_inode, 0);
+ data = audit_data_get(nd.dentry->d_inode, 0, 1);
if (!data)
goto audit_remove_watch_release;
@@ -562,7 +563,7 @@ void audit_update_watch(struct dentry *d
/* If there's no audit data on the parent inode, then there can
be no watches to add or remove */
- parent = audit_data_get(dentry->d_parent->d_inode, 0);
+ parent = audit_data_get(dentry->d_parent->d_inode, 0, 0);
if (!parent)
return;
@@ -571,7 +572,7 @@ void audit_update_watch(struct dentry *d
/* Fetch audit data, using the preallocated one from the watch if
there is actually a relevant watch and the inode didn't already
have any audit data */
- data = audit_data_get(dentry->d_inode, !!watch);
+ data = audit_data_get(dentry->d_inode, !!watch, remove);
/* If there's no data, then there wasn't a watch either.
Nothing to see here; move along */
@@ -786,7 +787,7 @@ void audit_inode_free(struct inode *inod
{
struct audit_watch *watch;
struct hlist_node *pos, *tmp;
- struct audit_inode_data *data = audit_data_get(inode, 0);
+ struct audit_inode_data *data = audit_data_get(inode, 0, 1);
if (data) {
spin_lock(&auditfs_hash_lock);
@@ -851,7 +852,7 @@ void audit_notify_watch(struct inode *in
if (!inode || !current->audit_context)
return;
- data = audit_data_get(inode, 0);
+ data = audit_data_get(inode, 0, 0);
if (!data)
return;
19 years, 1 month
Qusetion on logging file deletions with auditd
by Walt Powell
What would the appropriate syscall be in the audit.rules file to log file deletions with auditd? I'm thinking the syntax would be something akin to -w entry, always -S delete, but that doesn't seem to work...
Thanks to all...
19 years, 1 month
audit 1.4 released
by Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit It will also be in rawhide
tomorrow. The Changelog is:
- New report about authentication attempts
- Updates for python 2.5
- update autrace to have resource usage mode
- update auditctl to support immutable config
- added audit_log_user_command function to api
- interpret capabilities
- added audit event parsing library
- updates for 2.6.20 kernel
There is a major new feature in this release. This represents the first cut at
the audit parsing library. This version should be mostly complete except the
audit searching functions. They will be filled in during subsequent updates.
There is a test program in auparse/test that can be used to exercise the code
that is in the library. This drop also includes python bindings.
Please let me know if there are any problems with this release.
-Steve
19 years, 1 month
Running auditd from inittab
by Matthew Booth
I was testing various failures of auditd, and amongst them I tested kill
-SEGV and kill -KILL. I noticed that neither of these generate any audit
event or log activity. It occurs to me that this could be worked around,
and at the same time you could provide some additional level of
reliability, if auditd could be run from inittab. Unfortunately, the
only option to auditd seems to be -f, and this prevents it from logging
in the normal manner.
Are there any other options which might achieve this? If not, is this a
reasonable feature request?
Thanks,
Matt
--
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
19 years, 1 month
Detecting gaps in the audit record
by Matthew Booth
I notice that in normal operation audit event IDs are sequential. Is it
sufficient to look for non-sequential audit events to detects gaps in
the record? Are there any circumstances, including deliberate tampering,
where this might not be sufficient?
Thanks,
Matt
--
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
19 years, 1 month
Detecting gaps in the audit record
by Matthew Booth
I notice that in normal operation audit event IDs are sequential. Is it
sufficient to look for non-sequential audit events to detects gaps in
the record? Are there any circumstances, including deliberate tampering,
where this might not be sufficient?
Thanks,
Matt
--
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
19 years, 1 month
