Dispatcher - single line output (perl)
by Leigh Purdie
There have been a few requests on this list for a
single-line-per-event output format.
>From what I understand, supporting this feature in the kernel is a
little challenging due to the potential memory/cache requirements -
having to save off the 'pieces' of an event from initiation to exit,
could be quite expensive when we're talking in-kernel resources.
Hence, we're left with an audit output that could:
* Have an arbitrary number of lines per unique event,
* Be chronologically distributed in some cases (event lines may be
spread over several seconds),
* Be out of sequence (numerically - two lines from event A, might be
followed by 1 line from event B, then another line from event A,
followed by the rest of event B).
* Have multiple 'items' with the same name (eg: source/dest UID's for
a CHMOD have the same 'name/key', though they are on different lines).
(Please let me know if these assumptions are incorrect!)
However, the dispatcher infrastructure offers the potential to
implement this sort of functionality in user-space.
As such, I've been playing with some perl that should translate
SYSCALL events to something that should be reasonably parse-able by
follow-on processing applications that expect events in a single-line
form (eg: logwatch, a SQL-based data injector, Snare or Snare Server).
Here's a sample line. Note that events are in header/data format (tab
delimited between components, comma delimited within a component).
rhel4 LinuxKAudit event,11,20060509 06:36:25
user,0(root),0(root),0(root),0(root) process,25068,id
path,/usr/bin/id return,0,yes a0,9f96ba8 a1,9f96b28
a2,9f84b40 a3,9f96b28 arch,40000003 auid,4294967295
exe,/usr/bin/id fsgid,0 fsuid,0 items,2 sgid,0 suid,0
The program works roughly as follows:
while read line
break line up into key/value pairs
pop the key/value data into an associative array (with a key of the
event number)
if we have an items=x key/value pair saved off for this event
number, and we have 'x' PATH-related lines now, then we must have a
complete event. Push it out.
ALSO push out any events that we haven't had any new lines for, for
more than 15 seconds.
..
We also getpwname/getgrname (with an internal cache to avoid recursive
audit events), and an internal simple realpath() to turn
/path/to/blah/../../to/somewhere into /path/to/somewhere.
The raw perl is attached. Does anyone have any comments, or
suggestions? (I don't care about structure at this point - it's early
days yet - I'm sure perl aficionados could do the entire program in a
single line).
In particular, comments would be welcome on how to absolutely,
programatically determine when an 'event' is complete, and it is safe
to push out our final 'line'.
Regards,
Leigh.
18 years, 4 months
cups userspace -- trusted programs?
by Michael C Thompson
Hey all,
I'm wondering if the intent of the cups userspace tools are to be
trusted programs? Specifically I'm curious about cupsaccept, cupsreject,
cupsenable and cupsdisable. The reason I ask is because if they are
supposed to be trusted programs, they don't generate unique audit
messages like other programs.
Personally, I think these tools should generate messages since they are
a source for leaking information, and therefore should be restricted to
administrators.
Thanks,
Mike
18 years, 7 months
[Fwd: [PATCH] remove unnecessary return value of audit_avc_path]
by Steven Rostedt
(I'm resending this as I've been told, to CC linux-audit. I'm also
adding Al Viro too.)
Is there any reason that audit_avc_path has a return value? The only
two places in the kernel that it is used, the value is ignored, and when
it is turned off, we get a silly warning about "statement with no
effect". Even the comment above the function states that it is only
used in one file.
So this patch removes the need to have a return value.
-- Steve
Signed-off-by: Steven Rostedt
Index: linux-2.6.17-rc5/include/linux/audit.h
===================================================================
--- linux-2.6.17-rc5.orig/include/linux/audit.h 2006-05-30 14:39:22.000000000 -0400
+++ linux-2.6.17-rc5/include/linux/audit.h 2006-05-30 14:39:45.000000000 -0400
@@ -324,7 +324,7 @@ extern int audit_ipc_obj(struct kern_ipc
extern int audit_ipc_set_perm(unsigned long qbytes, uid_t uid, gid_t gid, mode_t mode, struct kern_ipc_perm *ipcp);
extern int audit_socketcall(int nargs, unsigned long *args);
extern int audit_sockaddr(int len, void *addr);
-extern int audit_avc_path(struct dentry *dentry, struct vfsmount *mnt);
+extern void audit_avc_path(struct dentry *dentry, struct vfsmount *mnt);
extern void audit_signal_info(int sig, struct task_struct *t);
extern int audit_set_macxattr(const char *name);
#else
@@ -344,7 +344,7 @@ extern int audit_set_macxattr(const char
#define audit_ipc_set_perm(q,u,g,m,i) ({ 0; })
#define audit_socketcall(n,a) ({ 0; })
#define audit_sockaddr(len, addr) ({ 0; })
-#define audit_avc_path(dentry, mnt) ({ 0; })
+#define audit_avc_path(dentry, mnt) do { ; } while (0)
#define audit_signal_info(s,t) do { ; } while (0)
#define audit_set_macxattr(n) do { ; } while (0)
#endif
Index: linux-2.6.17-rc5/kernel/auditsc.c
===================================================================
--- linux-2.6.17-rc5.orig/kernel/auditsc.c 2006-05-30 14:40:00.000000000 -0400
+++ linux-2.6.17-rc5/kernel/auditsc.c 2006-05-30 14:41:56.000000000 -0400
@@ -1292,21 +1292,19 @@ int audit_sockaddr(int len, void *a)
* @dentry: dentry to record
* @mnt: mnt to record
*
- * Returns 0 for success or NULL context or < 0 on error.
- *
* Called from security/selinux/avc.c::avc_audit()
*/
-int audit_avc_path(struct dentry *dentry, struct vfsmount *mnt)
+void audit_avc_path(struct dentry *dentry, struct vfsmount *mnt)
{
struct audit_aux_data_path *ax;
struct audit_context *context = current->audit_context;
if (likely(!context))
- return 0;
+ return;
ax = kmalloc(sizeof(*ax), GFP_ATOMIC);
if (!ax)
- return -ENOMEM;
+ return;
ax->dentry = dget(dentry);
ax->mnt = mntget(mnt);
@@ -1314,7 +1312,7 @@ int audit_avc_path(struct dentry *dentry
ax->d.type = AUDIT_AVC_PATH;
ax->d.next = context->aux;
context->aux = (void *)ax;
- return 0;
+ return;
}
/**
18 years, 7 months
What is expected: exclude action on the never list?
by Michael C Thompson
Hey Steve,
I'm doing some testing (a rare occurrence I know), and I've noticed that
when the active rules are:
auditctl -a entry,always -S chmod
auditctl -a exclude,always -F msgtype=SYSCALL
The chmod actions are not logged. Now this is what I would expect to
happen when just reading those lines, not knowing about the internal
workings of audit. However, if the rules are
auditctl -a entry,always -S chmod
auditctl -a exclude,never -F msgtype=SYSCALL
the chmod actions are not logged either. I would read the second rule as
saying "do not exclude messages of type SYSCALL". Is this a correct
interpretation of the rule?
Thanks,
Mike
18 years, 7 months
path filter keyword and relational operators
by Michael C Thompson
Hey Steve,
Should the path filter keyword accept any relational operator other than
equals (=) ? It would be possible to express the other relations in
terms of the return from strcmp, but I'm not sure if that is what is
desired for this field.
Thanks,
Mike
18 years, 7 months
[PATCH git] fix null dereference in fs audit patch
by Amy Griffis
Check watch pointer before dereferencing.
Al, please fold in with latest filesystem auditing patch
1d9d3267853cc4368c923f1ab7037db8c8805b73.
Signed-off-by: Amy Griffis <amy.griffis(a)hp.com>
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 7f2fcd6..f993842 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1032,12 +1032,13 @@ static inline int audit_do_del_rule(stru
list_for_each_entry(e, list, list) {
struct audit_watch *watch = e->rule.watch;
- struct audit_parent *parent = watch->parent;
if (audit_compare_rule(&entry->rule, &e->rule))
continue;
if (watch) {
+ struct audit_parent *parent = watch->parent;
+
list_del(&e->rule.rlist);
if (list_empty(&watch->rules)) {
--
1.3.0
18 years, 7 months
[patch] Full relabel audit event
by James Antill
The attached patch implements the full relabel audit event (Ie. an
audit event occurs when a full relabel occurs, ie. when /.autorelabel
exists at boot).
Note that although the code is correct, this patch doesn't actually
work due to kernel bugs[1].
It'll be in Fedora development as part of policycoreutils-1.30.10-3
onwards.
[1] see the thread on linux-audit if you want the details.
--
James Antill <jantill(a)redhat.com>
18 years, 7 months
RE: audit 1.2.2 released
by Chad Hanson
Comments below...
>
> I've been running mostly on an i686 (Intel) with the .27 kernel and
> 1.2.2 tools with the MLS policy. I've tested this on an x86_64 (AMD
> opteron) and see this problem too. However, this problem does
> NOT exist
> when using targeted policy, so it is most likely an MLS SELinux issue.
> My MLS policy is 2.2.42
>
> > Can you describe more about your configuration and provide exact steps
> > to reproduce the problem?
>
> 1) Reboot your system (so you've a clean slate)
> 2) Login (tty or pty, doesn't matter, I've done both)
> 3) auditctl -l
> Error sending rule list request (Operation not permitted)
> 4) auditctl -l
> No rules (or whatever you expect to see)
Are you running enforcing or permissive?
I only see this behavior on the LSPP kernels (including 28) after
transitioning to permissive mode, but not on the FC5 2.6.15 2054 kernel
running MLS with the same procedures.
Also, I don't see this behavior the same way. I can reboot, login, newrole
to auditadm_r and run auditctl -l correctly everytime.
The problem behavior I see is as follows below
1) newrole to secadm_r
2) auditctl -l -- denied as expected.
3) setenforce 0
4) auditctl -l -- denied (WRONG)
5) auditctl -l -- works correctly (can repeat as many times as desired)
6) setenforce 1 -- everything is back to normal
repeat from #3 to see problems again
-Chad
18 years, 7 months
auditctl se_sen & se_clr
by Michael C Thompson
Hey all,
I'm trying to figure out how the se_sen and se_clr labels are supposed
to be used with auditctl.
Here is the selinux context:
subj=root:staff_r:staff_t:s0-s15:c0.c255
^ ^ ^ ^
se_user ^ se_type ^
se_role se_clr & se_sen
What is the difference between se_clr and se_sen? And if you have any
enlightening examples, that would be appreciated.
Thanks,
Mike
18 years, 7 months
audit 1.2.3 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:
- Apply patch to ensure watches only associate with exit filter
- Apply patch to correctly show new operators when new listing format is used
- Apply patch to pull kernel's audit.h into python bindings
- Collect signal sender's context
Please let me know if there are any problems with this release.
-Steve
18 years, 7 months
