close(2) not being audited?
by Todd, Charles
All,
I'm on an RHEL4u3 with Steve's preliminary 1.0.15 package (I built the
RPM) under x86_64 2.6.9-34-ELsmp. I'm using the CAPP.rules sample
fileset to great success. NISPOM 8-602 requires that CLOSE operations
on security-relevant objects be logged. Well, I've got logging for OPEN
on security-relevant objects (with the watches) working VERY well
(yeah!!!). The default CAPP.rules file had nothing about close(2), so
just to test it, I ran:
auditctl -a entry,possible -S close
and then as a normal user typed: cat /etc/group (which is a
security-relevant object that I have permission to open, and thus
eventually close)
However, when I review the audit files, nothing is logged. If I change
the "entry,possible" to "entry,always" then lots of stuff gets logged,
but not my actual opening of the /etc/group file.
There is only one other thing that could be a configuration issue:
"auditctl -l |grep /etc/group" reveals an additional "perm=wa" field
that is set by the -p option in CAPP.rules, but even if root writes to
one of the watched files, close(2) is still not logged.
Do I have a configuration problem or is something deeper going on?
Thanks,
Charlie Todd
Ball Aerospace & Technologies Corp.
ctodd- at -ball.com
17 years, 9 months
Audit config for NISPOM req's
by Curtas, Anthony R.
Hello all,
I've been a linux sysadmin for a while for a small network of systems
under the oversight of the Defense Security Service (DSS). They have
always given us grief over Linux's inability to log certain events. A
year ago, I implemented Snare with good results, but lack of a Kernel
panic on audit failure always had them second guessing our setup. So
I'm encouraged to see the progress made here and am preparing to try
again.
Basically, the requirements are to log improper read access to certain
files (audit logs, shadow) and write access to many others (most of
/etc), and in some cases attempts to execute programs like stunnel and
su.
My main confusion on getting started is the difference between syscalls
and watches. It seems watches can do almost all of what I need, but
they seem to be less "configurable" than the syscalls (like ignoring if
root changes anything). Can someone explain the difference and where
one is more appropriate than the other.
I have the CAPP documents from HP and IBM, which seem to be a good
starting point (especially the conf files) - but I'm trying to
understand it all before implementation in case I need to tweak it.
Thanks in advance for any help,
Anthony
_____________
Anthony Curtas
SAIC, Division 35
17 years, 9 months
content and format?
by John Calcote
So what's in the future for linux audit regarding content and format? My company's really interested in this aspect of audit in order to provide good analytical tools for audit logs.
Anyone?
-----
John Calcote (jcalcote(a)novell.com)
Sr. Software Engineeer
Novell, Inc.
17 years, 10 months
[PATCH 00/10] Introduction
by Matt Helsley
This is version 2 of my Task Watchers patches with performance enhancements.
Task watchers calls functions whenever a task forks, execs, changes its
[re][ug]id, or exits.
Task watchers is primarily useful to existing kernel code as a means of making
the code in fork and exit more readable. Kernel code uses these paths by
marking a function as a task watcher much like modules mark their init
functions with module_init(). This improves the readability of copy_process().
The first patch adds the basic infrastructure of task watchers: notification
function calls in the various paths and a table of function pointers to be
called. It uses an ELF section because parts of the table must be gathered
from all over the kernel code and using the linker is easier than resolving
and maintaining complex header interdependencies. Furthermore, using a list
proved to have much higher impact on the size of the patches and was deemed
unacceptable overhead. An ELF table is also ideal because its "readonly" nature means that no locking nor list traversal are required.
Subsequent patches adapt existing parts of the kernel to use a task watcher
-- typically in the fork, clone, and exit paths:
FEATURE (notes) RELEVANT CONFIG VARIABLE
-----------------------------------------------------------------------
audit [ CONFIG_AUDIT ... ]
semundo [ CONFIG_SYSVIPC ]
cpusets [ CONFIG_CPUSETS ]
mempolicy [ CONFIG_NUMA ]
trace irqflags [ CONFIG_TRACE_IRQFLAGS ]
lockdep [ CONFIG_LOCKDEP ]
keys (for processes -- not for thread groups) [ CONFIG_KEYS ]
process events connector [ CONFIG_PROC_EVENTS ]
TODO:
Mark the task watcher table ELF section read-only. I've tried to "fix"
the .lds files to do this with no success. I'd really appreciate help
from folks familiar with writing linker scripts.
I'm working on three more patches that add support for creating a task
watcher from within a module using an ELF section. They haven't recieved
as much attention since I've been focusing on measuring the performance
impact of these patches.
Changes:
since v2 ():
Added ELF section annotations to the functions handling the events
Added section annotation to the lookup table in kernel/task_watchers.c
Added prefetch hints to the function pointer array walk
Renamed the macros (better?)
Retested the patches
Reduced noise in test results (0.6 - 1%, 2+% previously)
With the last prefetch patch I was able to measure a performance increase in
the range of 0.4 to 2.8%. I sampled 100 times and took the mean for each patch.
Since the numbers seemed to be a source of confusion last time I've tried to
simplify them here:
Patch Mean (forks/second)
0 6925.16 (baseline)
1 7170.81 task watchers
2 7100.34 audit
3 7114.47 semundo
4 7185.7 cpusets
5 7121.41 numa-mempolicy
6 7070.82 irqflags
7 7012.61 lockdep
8 7116.54 keys
9 7116.35 procevents
12 7109.52 prefetch
----------------------------------------------------
7109.52 - 6925.16 = +184 forks/second (+2.6%)
So the patch series now actually improves performance a little.
All the numbers from the tests are available if anyone wishes to analyze them
independently.
Please consider for inclusion in -mm.
Cheers,
-Matt Helsley
17 years, 10 months
Re: Task watchers v2
by Matt Helsley
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote:
> > Associate function calls with significant events in a task's lifetime much like
> > we handle kernel and module init/exit functions. This creates a table for each
> > of the following events in the task_watchers_table ELF section:
> >
> > WATCH_TASK_INIT at the beginning of a fork/clone system call when the
> > new task struct first becomes available.
> >
> > WATCH_TASK_CLONE just before returning successfully from a fork/clone.
> >
> > WATCH_TASK_EXEC just before successfully returning from the exec
> > system call.
> >
> > WATCH_TASK_UID every time a task's real or effective user id changes.
> >
> > WATCH_TASK_GID every time a task's real or effective group id changes.
> >
> > WATCH_TASK_EXIT at the beginning of do_exit when a task is exiting
> > for any reason.
> >
> > WATCH_TASK_FREE is called before critical task structures like
> > the mm_struct become inaccessible and the task is subsequently freed.
> >
> > The next patch will add a debugfs interface for measuring fork and exit rates
> > which can be used to calculate the overhead of the task watcher infrastructure.
>
> What's the point of the ELF hackery? This code would be a lot simpler
> and more understandable if you simply had task_watcher_ops and a
> register / unregister function for it.
A bit more verbose response:
I posted a notifier chain implementation back in June that bears some
resemblance to your suggestion -- a structure needed to be registered at
runtime. There was a single global list of them to iterate over for each
event.
This patch and the following patches are significantly shorter than
their counterparts in that series. They avoid iterating over elements
with empty ops. The way function pointers and function bodies are
grouped together by this series should improve locality. The fact that
there's no locking required also makes it simpler to analyze and use.
The patches to allow modules to register task watchers does make things
more complex though -- that does require a list and a lock. However, the
lock does not need to be taken in the fork/exec/etc paths if we pin the
module. In contrast your suggested approach is simpler because it
doesn't treat modules any differently. However overall I think the
balance still favors these patches.
Cheers,
-Matt Helsley
17 years, 10 months
Re: Task watchers v2
by Matt Helsley
On Fri, 2006-12-15 at 09:34 +0100, Christoph Hellwig wrote:
> On Thu, Dec 14, 2006 at 04:07:55PM -0800, Matt Helsley wrote:
> > Associate function calls with significant events in a task's lifetime much like
> > we handle kernel and module init/exit functions. This creates a table for each
> > of the following events in the task_watchers_table ELF section:
> >
> > WATCH_TASK_INIT at the beginning of a fork/clone system call when the
> > new task struct first becomes available.
> >
> > WATCH_TASK_CLONE just before returning successfully from a fork/clone.
> >
> > WATCH_TASK_EXEC just before successfully returning from the exec
> > system call.
> >
> > WATCH_TASK_UID every time a task's real or effective user id changes.
> >
> > WATCH_TASK_GID every time a task's real or effective group id changes.
> >
> > WATCH_TASK_EXIT at the beginning of do_exit when a task is exiting
> > for any reason.
> >
> > WATCH_TASK_FREE is called before critical task structures like
> > the mm_struct become inaccessible and the task is subsequently freed.
> >
> > The next patch will add a debugfs interface for measuring fork and exit rates
> > which can be used to calculate the overhead of the task watcher infrastructure.
>
> What's the point of the ELF hackery? This code would be a lot simpler
> and more understandable if you simply had task_watcher_ops and a
> register / unregister function for it.
Andrew asked me to avoid locking and added complexity in the code that
uses one or more task watchers. The ELF hackery helps me avoid locking
in the fork/exit/etc paths that call the "registered" function.
Cheers,
-Matt Helsley
17 years, 10 months
[PATCH] minor update to rule add/delete messages (ver 2)
by Steve Grubb
Hi,
I was looking at parsing some of these messages and found that I wanted what
it was doing next to an op= for the parser to key on. Also missing was the list
number and results.
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
diff -urp linux-2.6.18.x86_64.orig/kernel/auditfilter.c linux-2.6.18.x86_64/kernel/auditfilter.c
--- linux-2.6.18.x86_64.orig/kernel/auditfilter.c 2006-12-14 09:59:04.000000000 -0500
+++ linux-2.6.18.x86_64/kernel/auditfilter.c 2006-12-14 10:02:39.000000000 -0500
@@ -938,9 +938,10 @@ static void audit_update_watch(struct au
}
ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
- audit_log_format(ab, "audit updated rules specifying path=");
+ audit_log_format(ab, "op=updated rules specifying path=");
audit_log_untrustedstring(ab, owatch->path);
audit_log_format(ab, " with dev=%u ino=%lu\n", dev, ino);
+ audit_log_format(ab, " list=%d res=1", r->listnr);
audit_log_end(ab);
audit_remove_watch(owatch);
@@ -970,14 +971,14 @@ static void audit_remove_parent_watches(
e = container_of(r, struct audit_entry, rule);
ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONFIG_CHANGE);
- audit_log_format(ab, "audit implicitly removed rule path=");
+ audit_log_format(ab, "op=remove rule path=");
audit_log_untrustedstring(ab, w->path);
if (r->filterkey) {
audit_log_format(ab, " key=");
audit_log_untrustedstring(ab, r->filterkey);
} else
audit_log_format(ab, " key=(null)");
- audit_log_format(ab, " list=%d", r->listnr);
+ audit_log_format(ab, " list=%d res=1", r->listnr);
audit_log_end(ab);
list_del(&r->rlist);
@@ -1411,7 +1412,7 @@ static void audit_log_rule_change(uid_t
audit_log_format(ab, " subj=%s", ctx);
kfree(ctx);
}
- audit_log_format(ab, " %s rule key=", action);
+ audit_log_format(ab, " op=%s rule key=", action);
if (rule->filterkey)
audit_log_untrustedstring(ab, rule->filterkey);
else
17 years, 10 months
Current capabilities
by Michael W Folsom
I've been lurking on this list for a while now and am a bit confused at
the current state of audit's capabilities. I've looked at:
http://people.redhat.com/sgrubb/audit/
and still aren't sure if it is capable of doing what I need. To get to
the point the events I need to record in an audit log are -
1) If someone tries to access an object (file, directory, program) that
they don't have rights to the event needs to be recorded
2) if someone logs into a system and su's to another user or series of
users their actions need to be traceable to the original login user's
id
Can this be done with the current audit system in RHEL4 or will this not
be supported until RHEL5 is released? Are there any other Linux
distro's that can do this? If either of these are true where would I
look for information how to get this to work.
Thanks!
17 years, 10 months
RE: Linux-audit Digest, Vol 27, Issue 2
by Thomas, Daniel J.
I'm new to the audit subsystem. I need to get it working well under
RHEL4. The version that comes with Redhat is very old (1.0.14?) I
noticed if I upgrade to 1.0.14 it pretty much works the same, but if I
upgrade all the way to 1.3.1, file watch functionality has been removed.
How do I handle auditing of access to security files with 1.3? I assume
it's some kind of system call we're tracking, but I don't know how to
get a list of system calls that I need to know about.
Thanks,
-Dan Thomas
-----Original Message-----
From: linux-audit-bounces(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of
linux-audit-request(a)redhat.com
Sent: Monday, December 11, 2006 12:00 PM
To: linux-audit(a)redhat.com
Subject: Linux-audit Digest, Vol 27, Issue 2
Send Linux-audit mailing list submissions to
linux-audit(a)redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
linux-audit-request(a)redhat.com
You can reach the person managing the list at
linux-audit-owner(a)redhat.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Linux-audit digest..."
Today's Topics:
1. audit 1.3.1 released (Steve Grubb)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Dec 2006 11:05:33 -0500
From: Steve Grubb <sgrubb(a)redhat.com>
Subject: audit 1.3.1 released
To: Linux Audit <linux-audit(a)redhat.com>
Message-ID: <200612111105.33708.sgrubb(a)redhat.com>
Content-Type: text/plain; charset="us-ascii"
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:
- Fix a couple parsing problems (#217952)
- Add tgkill to S390* syscall tables (#218484)
- Fix error messages in ausearch/aureport command options
Please let me know if there are any problems with this release.
-Steve
------------------------------
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
End of Linux-audit Digest, Vol 27, Issue 2
******************************************
17 years, 10 months
Executable permissions
by Karl MacMillan
Is there a reason that the audit tools that take a file name paramater
(-if) are not executable by non-root users? This prevents their use by
an admin to do analysis of saved audit logs with an unprivileged user login.
Thanks - Karl
17 years, 10 months
