(no subject)
by Kirkwood, David A.
How do I place a watch on files that are being rotated? For example: I
want to audit the audit logs themselves , and when they are rotated I
need to watch the new audit log that is created as well as the rotated
logs.
Thanks,
David A. Kirkwood
19 years
AVC field names
by John Dennis
There are two fields in AVC audit messages which do not have a name, the
result and the access permissions (what is inside the braces {}).
In setroubleshoot we named the result "grant" and we named the access
permissions "access".
I see in auparse they have been named "seresults" and "seperms"
respectively.
Why is "seresults" plural? It's a single value isn't it?
Are these names in wide use? I ask because for sanity sake I don't want
to be in the business of translating names between libraries, just too
confusing, let's aim for consistency. My general impression was "access"
was way that items inside the braces were referred to in much of the
SELinux documentation. So based on what is out in the field and
anticipated usage should we be using:
"grant" & "access"
-OR-
"seresults" & "seperms" (seresult?)
I'll change one or the other, just don't want to have both in play at
the same time.
--
John Dennis <jdennis(a)redhat.com>
19 years
[PATCH] audit: fix broken class-based syscall audit
by Klaus Weidner
Bug description: When I add an audit watch on a file with no arguments, I
get perm=rwxa but on ia64, changes to the mode and context aren't
audited. I get audit records on i386 and x86_64.
(from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239887 )
The sanity check in audit_match_class() is wrong, AUDIT_BITMASK_SIZE is
64, providing space for 2048 syscalls in 64 * 32bit integers. The
comparison only supports 256 syscalls (sizeof __u32 is 4), and silently
returns "no match" for valid higher-numbered syscalls.
This breaks class-based audit for all syscalls on ia64 since on that
architecture syscall numbers start at 1024. It breaks some syscall audit
on other architectures also, for example __NR_fchmodat is 306 on x86.
I'd suggest adding a printk() in addition to returning 0 - you don't want
to silently ignore unknown or unsupported syscalls when auditing.
Signed-off-by: Klaus Weidner <klaus(a)atsec.com>
Followup discussion was on the linux-audit mailing list:
https://www.redhat.com/archives/linux-audit/2007-May/msg00030.html
Acked-by: Al Viro <viro(a)zeniv.linux.org.uk>
--- linux-2.6.18.i686/kernel/auditfilter.c.lspp.80 2007-05-11 17:06:08.000000000 -0500
+++ linux-2.6.18.i686/kernel/auditfilter.c 2007-05-11 17:09:37.000000000 -0500
@@ -306,7 +306,7 @@
int audit_match_class(int class, unsigned syscall)
{
- if (unlikely(syscall >= AUDIT_BITMASK_SIZE * sizeof(__u32)))
+ if (unlikely(syscall >= AUDIT_BITMASK_SIZE * 32))
return 0;
if (unlikely(class >= AUDIT_SYSCALL_CLASSES || !classes[class]))
return 0;
19 years
[PATCH] fix broken class-based syscall audit
by Klaus Weidner
Bug description: When I add an audit watch on a file with no arguments, I
get perm=rwxa but on ia64, changes to the mode and context aren't
audited. I get audit records on i386 and x86_64.
See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239887
The sanity check in audit_match_class() is wrong, AUDIT_BITMASK_SIZE is
64, providing space for 2048 syscalls in 64 * 32bit integers. The
comparison only supports 256 syscalls (sizeof __u32 is 4), and silently
returns "no match" for valid higher-numbered syscalls.
This breaks class-based audit for all syscalls on ia64 since on that
architecture syscall numbers start at 1024. It breaks some syscall audit
on other architectures also, for example __NR_fchmodat is 306 on x86.
I'd suggest adding a printk() in addition to returning 0 - you don't want
to silently ignore unknown or unsupported syscalls when auditing.
Signed-off-by: Klaus Weidner <klaus(a)atsec.com>
--- linux-2.6.18.i686/kernel/auditfilter.c.lspp.80 2007-05-11 17:06:08.000000000 -0500
+++ linux-2.6.18.i686/kernel/auditfilter.c 2007-05-11 17:09:37.000000000 -0500
@@ -306,7 +306,7 @@
int audit_match_class(int class, unsigned syscall)
{
- if (unlikely(syscall >= AUDIT_BITMASK_SIZE * sizeof(__u32)))
+ if (unlikely(syscall >= AUDIT_BITMASK_SIZE * 32))
return 0;
if (unlikely(class >= AUDIT_SYSCALL_CLASSES || !classes[class]))
return 0;
19 years
watches using -p omit some syscalls
by Linda Knippers
I was doing some testing on the lspp .80 kernel and discovered that when
issuing a simple watch on ia64, I didn't get audit records as I expected.
For example, auditctl -w /foo, which defaults to -p rwxa, followed by a
chmod or a chcon on the file generated no audit records.
I filed this bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239887
The problem exists but is less severe on other architectures.
Klaus posted a patch in the bugzilla (see below) and also recommended
that unknown syscalls not be silently ignored.
I have tested Klaus' patch and it solves the problem I saw on ia64. I'm sure
Klaus would be happy to post a signed off patch.
-- ljk
--- linux-2.6.18.i686/kernel/auditfilter.c.lspp.80 2007-05-11 17:06:08.000000000 -0500
+++ linux-2.6.18.i686/kernel/auditfilter.c 2007-05-11 17:09:37.000000000 -0500
@@ -306,7 +306,7 @@
int audit_match_class(int class, unsigned syscall)
{
- if (unlikely(syscall >= AUDIT_BITMASK_SIZE * sizeof(__u32)))
+ if (unlikely(syscall >= AUDIT_BITMASK_SIZE * 32))
return 0;
if (unlikely(class >= AUDIT_SYSCALL_CLASSES || !classes[class]))
return 0;
19 years
Format of audit logs
by Matthew Booth
Can anybody point me to a document which describes the format of logs
generated by auditd in RHEL 4. This is for a customer, and is for human
consumption. I don't need to parse them. I know they're reasonably
self-explanatory, but it would be a significant amount of work to
document it myself.
Thanks,
Matt
--
Matthew Booth, RHCA, RHCSS
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
audit console traffic
by paul moore
Redhat es4 x86 monoproc
Kernel 2.6.9-34.EL
Audit 1.0.12-1.EL4
If I have audit turned on and some syscalls enabled and there is no
listening process then the audit subsystem pours its heart out on the
console
This situation occurs if I start my auditing app (that listens directly to
the audit subsystem using audit_get_reply) dies.
I know I should catch the death signal and disable auditing but is there a
way to stop the audit subsytem doing this anyway. I.e if nobody is listening
then just dump the traffic
I assumed it was syslog doing this but I have nothing in syslog.conf that
points at /dev/console. Maybe its printk doing it
19 years
hexified path in cwd audit message if dir no longer exists
by paul moore
Redhat es4 x86 monoproc
Kernel 2.6.9-34.EL
Audit 1.0.12-1.EL4
Occasiaonally I get a CWD audit message that has a hexified path in it.
Like this
$1 = "audit(1178324383.479:1566):
cwd=2F70726F632F35373336202864656C6574656429\000
This is "/proc/5736"
The message is coming from a shell process whose current dir is /proc/5736
and 5736 exited The cwd path contains junk after the "6" character - so
audit unstrusted string has hexified it I have not tried with real dirs
Bug?
19 years, 1 month
auditd shutdown issue
by Bill O'Donnell
Probably a FAQ, but I'm having some trouble stopping a system running
auditd.
Installed RHEL5 on X86-64 architecture presumably using default installation
parameters. Worked fine, booted fine, but when I shutdown (using init 0, halt,
etc.) the system starts scrolling pages and pages of the following messages
when it stops the auditd. The only way out is to power the system off or
restart auditd.
-----------------
The system is going down for system halt NOW!
[root@skynet15 ~Shutting down smartd: [ OK ]
Shutting down Avahi daemon: [ OK ]
Stopping HAL daemon: [ OK ]
----------------
Any help is appreciated.
Thx -
Bill
19 years, 1 month
Login/Logout events
by Robert Evans
Hi,
In doing some testing with the last audit module (testing on FC5) I found the
following behavior
1. login and logout events recorded from GDM login
2. login and logout events recorded from su
3. login events recorded from ssh connections, no logout events (USER_END) logged.
Is there something I need to do to catch these ssh disconnects?
Thanks,
Bob Evans
JHU/APL
19 years, 1 month
