[PATCH] log obj label when opening an existing mq
by Amy Griffis
Add an audit_inode() hook to mq_open() so audit will log the object
label for an existing POSIX message queue. Without this patch, audit
only logs the object label when a new message queue is created.
Untested patch against lspp.63 kernel.
Signed-off-by: Amy Griffis <amy.griffis(a)hp.com>
---
diff -Nrup linux-2.6.18.x86_64/ipc/mqueue.c linux-2.6.18.x86_64-amg/ipc/mqueue.c
--- linux-2.6.18.x86_64/ipc/mqueue.c 2007-01-23 17:17:06.000000000 -0500
+++ linux-2.6.18.x86_64-amg/ipc/mqueue.c 2007-01-23 18:25:25.000000000 -0500
@@ -642,6 +642,7 @@ static int oflag2acc[O_ACCMODE] = { MAY_
return ERR_PTR(-EINVAL);
}
+ audit_inode(dentry->d_name.name, dentry->d_inode);
if (permission(dentry->d_inode, oflag2acc[oflag & O_ACCMODE], NULL)) {
dput(dentry);
mntput(mqueue_mnt);
17 years, 11 months
[PATCH] initialize name osid in audit_getname()
by Amy Griffis
Audit contexts can be reused, so initialize a name's osid to the
default in audit_getname(). This ensures we don't log a bogus object
label when no inode data is collected for a name.
Untested patch against lspp.63 kernel.
Signed-off-by: Amy Griffis <amy.griffis(a)hp.com>
---
diff -Nrup linux-2.6.18.x86_64/kernel/auditsc.c linux-2.6.18.x86_64-amg/kernel/auditsc.c
--- linux-2.6.18.x86_64/kernel/auditsc.c 2007-01-23 17:17:07.000000000 -0500
+++ linux-2.6.18.x86_64-amg/kernel/auditsc.c 2007-01-23 17:20:35.000000000 -0500
@@ -1215,6 +1215,7 @@ void __audit_getname(const char *name)
context->names[context->name_count].name_len = AUDIT_NAME_FULL;
context->names[context->name_count].name_put = 1;
context->names[context->name_count].ino = (unsigned long)-1;
+ context->names[context->name_count].osid = 0;
++context->name_count;
if (!context->pwd) {
read_lock(¤t->fs->lock);
17 years, 11 months
two questions regarding default audit behavior
by Bill Tangren
I have two questions regarding default audit behavior (i.e. auditd is running,
but there is nothing in audit.rules but "-D" and "-b 256"):
1) what is being audited?
2) can I use the -D command to prevent those things from being audited?
I am required to have auditing running, but what I need to audit is specific.
One server in particular is slow (a 750 MHz Pentium III) to start with, and
default auditing is slowing it down to a crawl.
Bill Tangren
17 years, 11 months
Filtering
by Thomas, Daniel J.
Hello List,
Karen and I have been making good progress with our RHEL4 distro. Once
we got the kernel updated as suggested, we're getting logs captured
correctly. We found that we really don't need to use any file watches
at all, but rather capture exit code -13. We also found that capturing
exit code -1 would catch failed attempts to change permissions, owner,
attributes on the file.
Right now I have a problem with too many logs. We are seeing events
captured from opening and closing terminal windows both as root or as a
regular user.
I'm doing the following:
-a exit,always -S all -F exit=-13
-a exit,always -S 90 -F exit=-1
-a exit,always -S 92 -F exit=-1
By specifying the sys calls for exit code -13, it reduced the chatter
some, but still captured what we needed. I still get stuff from exit
code -13 however when I just open a terminal window. Here is an
example:
As root:
type=SYSCALL msg=audit(1168961366.396:39898): arch=c000003e syscall=21
success=no exit=-13 a0=6c4550 a1=1 a2=11 a3=0 items=1 pid=9636
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="bash" exe="/bin/bash"
type=CWD msg=audit(1168961366.396:39898): cwd="/root"
type=PATH msg=audit(1168961366.396:39898): name="/etc/bashrc" flags=401
inode=7553057 dev=08:05 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1168961366.416:39899): arch=c000003e syscall=21
success=no exit=-13 a0=6c7850 a1=1 a2=11 a3=2 items=1 pid=9636
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="bash" exe="/bin/bash"
type=CWD msg=audit(1168961366.416:39899): cwd="/root"
type=PATH msg=audit(1168961366.416:39899): name="/etc/sysconfig/i18n"
flags=401 inode=7556479 dev=08:05 mode=0100644 ouid=0 ogid=0 rdev=00:00
As user karen:
type=SYSCALL msg=audit(1168961386.899:39900): arch=c000003e syscall=2
success=no exit=-13 a0=33e7d192fa a1=2 a2=2 a3=8 items=1 pid=9654
auid=4294967295 uid=501 gid=100 euid=501 suid=501 fsuid=501 egid=100
sgid=100 fsgid=100 comm="tcsh" exe="/bin/tcsh"
type=CWD msg=audit(1168961386.899:39900): cwd="/home/karen"
type=PATH msg=audit(1168961386.899:39900): name="/var/run/utmp"
flags=101 inode=1867783 dev=08:02 mode=0100664 ouid=0 ogid=22
rdev=00:00
I thought maybe I could filter using flags 401 and 101, but I don't see
a way to do that. I also thought maybe using the arguments to syscall,
but they don't really seem constant enough to be certain of.
Any ideas?
Thanks!
-Dan Thomas
17 years, 11 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, 11 months
FW: Streaming output mode in audit.conf
by Bailey, Edward
After a little thinking I believe something like this might work
output {
mode = stream;
command = "|/usr/bin/nc -u "hostname" 514";
};
But when I start the audit daemon I get the following error and the
audit system shuts down
Jan 12 08:59:11 xxxxxxxxx auditd[1328]: output error; suspending
execution
Jan 12 08:59:11 xxxxxxxxx audit: auditd -TERM succeeded
Jan 12 08:59:15 xxxxxxxxx audit: auditd startup succeeded
Is their a way to start up the daemon in a verbose mode to get more
information or can someone tell me what is causing the error?
Thanks
Ed
> -----Original Message-----
> From: Bailey, Edward
> Sent: Thursday, January 11, 2007 4:40 PM
> To: 'linux-audit(a)redhat.com'
> Subject: Streaming output mode in audit.conf
>
> I am sure I am missing something obvious but I need help
> figuring out how to use the streaming output mode listed in
> audit.conf to stream audit info to syslog.
>
> The config file has:
>
> output {
> mode = stream;
> command = "/usr/local/sbin/send_to_syslog";
> };
>
> Using /usr/bin/logger does not work - I saw a reference to
> using popen() but nothing else. Any ideas?
>
> Thanks
>
> I really appreciate any help.
>
> Thanks
>
> Ed
------------------------
CONFIDENTIALITY NOTICE
This e-mail and any attachments contain information which may be confidential or privileged and exempt from disclosure under applicable law. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is without authorization and is prohibited. If you have received this email in error, please immediately notify us by returning it to the sender and delete this copy from your computer system. Thank you.
------------------------
17 years, 11 months
RE: Audit dispatcher process
by Todd, Charles
James,
Even though the xinetd model for plugins was probably a no-brainer
design decision, I still agree that it's an excellent choice. Thanks
for using that model. I don't know if you want to have signal (of some
kind) that must be issued in order for a new plugin to take effect.
Certainly, the addition of a new plugin should be an audited event, so
perhaps the CAPP-suggested list automatically includes a write/execute
watch on this directory.
I have a small suggestion for the local logging plugin that will
probably be put in by default:
* I recommend a file naming convention similar to that used under
Solaris. That is <init_datetime>.<close_datetime>.<host>
* <init_datetime> for 11Jan2007 at 3:46pm would be 20070111154632
* <close_datetime> is "not_terminated" when a file is currently being
written, although this is doesn't work when the dispatcher dies
prematurely
* <host> is usually not the FQDN, but allows lots of audit trail files
from lots of machines to be in one directory.
* Solaris administrators issues a "audit -n" to rotate the logs when
it's time, and this is occassionally quite handy when archiving logs
* Real-time compression (gzip) is a GREAT idea. If the binary file
written by the local logging plugin wrote whole records at a time, then
a leading bit could indicate compression. Being able to turn off
compression might help in high-load situations.
* Also being able to set a max file size before rotation becomes
mandatory makes it easy to archive audit logs to fixed-size media.
A suggestion I have for the plugin architecture is to allow the plugin
to query the dispatcher for internal statistics and system call
number-to-name lookups. Some internal statistics might be audit buffer
ring size, or other useful information to deal with high-load
environments. Most everything else, the plugin can ask the OS (system
date/time, system load, etc.)
Is the dispatcher responsible for restarting a plugin if the
process-killer targets it?
A useful plugin for any authors might be a UDP transmitter, with PKE for
all packets. This would allow a centralized repository in a trusted
environment.
Another plugin might be a real-time stream-to-tape so that audit trail
retention is as easy as replacing a tape when it's ejected because it
was full. By maintaining an open file descriptor at all times, other
processes will have a tough time overwriting audit trails.
Should anyone approach the Webmin authors once the API and directory
structure is locked in so that they can write a module?
Of course, I don't expect both of those to make it into the standard
distro, but rather maybe spark an interest among the group.
Thanks,
Charlie Todd
Ball Aerospace & Technologies Corp.
Ctodd- at -ball.com
> -----Original Message-----
> From: linux-audit-bounces(a)redhat.com
> [mailto:linux-audit-bounces@redhat.com] On Behalf Of James Antill
> Sent: Thursday, January 11, 2007 12:59 AM
> To: linux-audit(a)redhat.com
> Subject: Audit dispatcher process
>
>
> Steve has asked me to write the audit dispatcher, and after
> talking about it we already have some plans (as you'll see
> below :) but we would welcome input from people on this list.
> First to bring you all up to speed with what we know:
>
>
> . Development should be starting soon.
>
> . It will, at least initially, be distributed as part of the
> audit package.
>
> . We are planning to have a usable version for Fedora 7.
>
> . That initial version will be able to act as the dispatcher
> for auditd and (re-)send those messages to multiple plugins.
>
> . Those plugins can be shipped separately.
>
>
> ...and what seems very likely:
>
>
> . The plugins will be external applications.
>
> . The dispatcher itself will not be parsing audit messages
> and will be designed as a kind of Publish/Subscribe daemon.
>
> . In that vein, reuse of code from And-httpd/Vstr/etc.[1] is
> more than very likely.
>
> . The dispatcher will only be doing minimal content filtering
> for the plugins (this kind of falls out from the minimal parsing).
>
> . That message input will come from plugins, as well as the output.
>
> . They'll be a mode for the plugin to run in where it speaks
> a mini-protocol with the dispatcher, instead of just getting
> raw messages from auditd.
>
> . That the mini-protocol will allow "commands" to go back to
> the dispatcher (think remote server says "out of disk space,
> do X" or IDS says "attack happening from IP block X/y, do Z").
>
> . The initial set of plugins will contain at least something
> to connect the dispatcher to setroubleshootd and something
> for (secure) remote logging.
>
>
> I've probably missed something already, so if there's
> anything you want that isn't on the above list or anything
> that isn't clear and you want to clarify ... just hit reply :).
>
>
> [1] http://www.and.org/and-httpd/ and http://www.and.org/vstr/
>
> --
> James Antill - <james.antill(a)redhat.com> setsockopt(fd,
> IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd,
> IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd,
> SOL_SOCKET, SO_ATTACH_FILTER, ...);
>
>
17 years, 11 months
Streaming output mode in audit.conf
by Bailey, Edward
I am sure I am missing something obvious but I need help figuring out
how to use the streaming output mode listed in audit.conf to stream
audit info to syslog.
The config file has:
output {
mode = stream;
command = "/usr/local/sbin/send_to_syslog";
};
Using /usr/bin/logger does not work - I saw a reference to using popen()
but nothing else. Any ideas?
Thanks
I really appreciate any help.
Thanks
Ed
------------------------
CONFIDENTIALITY NOTICE
This e-mail and any attachments contain information which may be confidential or privileged and exempt from disclosure under applicable law. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is without authorization and is prohibited. If you have received this email in error, please immediately notify us by returning it to the sender and delete this copy from your computer system. Thank you.
------------------------
17 years, 11 months
Audit dispatcher process
by James Antill
Steve has asked me to write the audit dispatcher, and after talking
about it we already have some plans (as you'll see below :) but we would
welcome input from people on this list.
First to bring you all up to speed with what we know:
. Development should be starting soon.
. It will, at least initially, be distributed as part of the audit
package.
. We are planning to have a usable version for Fedora 7.
. That initial version will be able to act as the dispatcher for auditd
and (re-)send those messages to multiple plugins.
. Those plugins can be shipped separately.
...and what seems very likely:
. The plugins will be external applications.
. The dispatcher itself will not be parsing audit messages and will be
designed as a kind of Publish/Subscribe daemon.
. In that vein, reuse of code from And-httpd/Vstr/etc.[1] is more than
very likely.
. The dispatcher will only be doing minimal content filtering for the
plugins (this kind of falls out from the minimal parsing).
. That message input will come from plugins, as well as the output.
. They'll be a mode for the plugin to run in where it speaks a
mini-protocol with the dispatcher, instead of just getting raw messages
from auditd.
. That the mini-protocol will allow "commands" to go back to the
dispatcher (think remote server says "out of disk space, do X" or IDS
says "attack happening from IP block X/y, do Z").
. The initial set of plugins will contain at least something to connect
the dispatcher to setroubleshootd and something for (secure) remote
logging.
I've probably missed something already, so if there's anything you want
that isn't on the above list or anything that isn't clear and you want
to clarify ... just hit reply :).
[1] http://www.and.org/and-httpd/ and http://www.and.org/vstr/
--
James Antill - <james.antill(a)redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...);
17 years, 11 months
Other audit configurations
by Thomas, Daniel J.
Hello again, list,
My officemate is looking into some other auditd configurations, but we
were also looking for more information for something that might not be
related. We're running Redhat Enterprise 4 with audit 1.0.14-1. We're
trying to figure out where some of the other information is coming from
that is in our audit.log file. It seems to be pam information and such.
Where is that configured? Back in Redhat 9, pam messages were in
messages.log and only audit messages were in audit.log.
Thanks!
-Dan Thomas
17 years, 11 months
