user message limits
by LC Bruzenak
I know I can go look at the code, however I figured I'd ask here first
about the limits on the user message in both audit_log_user_message and
ausearch.
With audit_log_user_message the maximum length allowed appears to be
around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the
executable name length (and other stuff auto-pushed into the string)
which is why I say "around".
Even when I get a successful return value (from audit_log_user_message),
I don't get my string back out in "ausearch" unless it is WAY smaller -
~1K or less I think.
Any ideas/thoughts?
This is the latest (1.7.11-2) audit package.
Thx,
LCB.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
11 years, 1 month
linux-audit: reconstruct path names from syscall events?
by John Feuerstein
Hi,
I would like to audit all changes to a directory tree using the linux
auditing system[1].
# auditctl -a exit,always -F dir=/etc/ -F perm=wa
It seems like the GNU coreutils are enough to break the audit trail.
The resulting SYSCALL events provide CWD and multiple PATH records,
depending on the syscall. If one of the PATH records is relative, I can
reconstruct the absolute path using the CWD record.
However, that does not work for the whole *at syscall family
(unlinkat(2), renameat(2), linkat(2), ...); accepting paths relative to
a given directory file descriptor. GNU coreutils are prominent users,
for example "rm -r" making use of unlinkat(2) to prevent races.
Things like dup(2) and fd passing via unix domain sockets come to mind.
It's the same old story again: mapping fds to path names is ambiguous at
best, if not impossible.
I wonder why such incomplete file system auditing rules are considered
sufficient in the CAPP/LSPP/NISPOM/STIG rulesets?
Here's a simplified example:
$ cd /tmp
$ mkdir dir
$ touch dir/file
$ ls -ldi /tmp /tmp/dir /tmp/dir/file
2057 drwxrwxrwt 9 root root 380 Sep 17 00:02 /tmp
58781 drwxr-xr-x 2 john john 40 Sep 17 00:02 /tmp/dir
56228 -rw-r--r-- 1 john john 0 Sep 17 00:02 /tmp/dir/file
$ cat > unlinkat.c
#include <unistd.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
int dirfd = open("dir", O_RDONLY);
unlinkat(dirfd, "file", 0);
return 0;
}
^D
$ make unlinkat
cc unlinkat.c -o unlinkat
$ sudo autrace ./unlinkat
Waiting to execute: ./unlinkat
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 32121'
$ ls -li dir
total 0
Now, looking at the resulting raw SYSCALL event for unlinkat(2):
type=SYSCALL msg=audit(1316210542.899:779): arch=c000003e syscall=263 success=yes exit=0 a0=3 a1=400690 a2=0 a3=0 items=2 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:779): cwd="/tmp"
type=PATH msg=audit(1316210542.899:779): item=0 name="/tmp" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=PATH msg=audit(1316210542.899:779): item=1 name="file" inode=56228 dev=00:0e mode=0100644 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:779):
- From this event alone, there's no way to answer "Who unlinked
/tmp/dir/file?". For what it's worth, the provided path names would be
exactly the same if we had unlinked "/tmp/dir/dir/dir/dir/dir/file".
- PATH item 0 reports the inode of "/tmp/dir" (58781, see ls output
above), however, the reported path name is "/tmp" (bug?).
In this example I've used autrace, which traces everything, so I could
possibly search for a previous open(2) of inode 58781. And indeed, there
it is:
type=SYSCALL msg=audit(1316210542.899:778): arch=c000003e syscall=2 success=yes exit=3 a0=40068c a1=0 a2=7fff22724fc8 a3=0 items=1 ppid=32106 pid=32121 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts12 ses=36 comm="unlinkat" exe="/tmp/unlinkat" key=(null)
type=CWD msg=audit(1316210542.899:778): cwd="/tmp"
type=PATH msg=audit(1316210542.899:778): item=0 name="dir" inode=58781 dev=00:0e mode=040755 ouid=1000 ogid=1000 rdev=00:00
type=EOE msg=audit(1316210542.899:778):
Great, so inode 58781 was opened using "/tmp/dir", and therefore, the relative
path "file" given to unlinkat(2) above could possibly translate to
"/tmp/dir/path"... not really feeling confident here.
- All file system auditing rules in various rulesets and the examples in
the documentation add the "-F perm=wa" (or similar) filter, so the
open(2) wouldn't even make it into the audit trail.
- If you can handle the volume and log all open(2), what happens if the
open(2) was done hours, days, weeks, ... ago?
- What if the open(2) was done by another process which passed the fd
on a unix domain socket?
It looks like the kernel auditing code should provide
... item=0 name="/tmp/dir" inode=58781 ...
in the unlinkat(2) syscall event above. Looking up the unlinkat(2)
documentation:
int unlinkat(int dirfd, const char *pathname, int flags);
If the pathname given in pathname is relative, then it is
interpreted relative to the directory referred to by the file
descriptor dirfd (rather than relative to the current working
directory of the calling process, as is done by unlink(2) and
rmdir(2) for a relative pathname).
If the pathname given in pathname is relative and dirfd is the
special value AT_FDCWD, then pathname is interpreted relative
to the current working directory of the calling process (like
unlink(2) and rmdir(2)).
As you might see, there's not only the fd->pathname problem, but
also the special case for AT_FDCWD. In this case the kernel side should
probably just duplicate CWD's path name into item 0's path name. But
that's just unlinkat(2), there are a lot more.
What am I missing here? Is there no way to audit a directory tree?
I've looked at alternatives: Inotify watches won't scale to big trees
and events lack so much detail that they can't be used for auditing.
Fanotify, while providing the pid, still lacks a lot of events and
passes fds; the example code relies on readlink("/proc/self/fd/...").
Thanks,
John
[1] http://people.redhat.com/sgrubb/audit/
--
John Feuerstein <john(a)feurix.com>
12 years
AUDIT_SIGNAL_INFO
by Matthew Booth
Under what circumstances will the RHEL 4 kernel generate a message of
type AUDIT_SIGNAL_INFO? My understanding is that it should be sent when
a process sends a signal to the audit daemon, however I have not
observed that. Any ideas?
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
12 years, 4 months
Near Term Audit Road Map
by Steve Grubb
Hi,
With the proposals sent to the list, I wanted to talk about how this might
play out code-wise. With regard to the current code base, I am working on a
1.8 release. This would represent finishing the remote logging app and
nothing more. The 1.8 series would become just an update series just like the
1.0.x series did.
In parallel with finishing remote logging, I would release a 2.0 version.
Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would
signify the completion of remote logging that branch. I would recommend this
branch for all distributions pulling new code in.
The 2.0 branch will also have a couple more changes. I want to split up the
audit source code a little bit. I want to drop the system-config-audit code
and let it become standalone package updated and distributed separately.
I also want to drop all audispd-plugins in the 2.0 branch and have them
released separately. They cause unnecessary build dependencies for the audit
package.
During the work for a 2.2 release, I would also like to pull the audispd
program inside auditd. In the past, I tried to keep auditd lean and single
purpose, but with adding remote logging and kerberos support, we already have
something that is hard to analyze. So, to improve performance and decrease
system load, the audit daemon will also do event dispatching.
Would this proposal impact anyone in a Bad Way?
Thanks,
-Steve
12 years, 4 months
Daemon start problems
by Stephen Quinney
I'm seeing some problems with the audit daemon not starting at
boot-time on a RHEL6 machine. If I login as root after the boot
sequence has finished it can be manually started without any
problems. At first I thought this might be a bad interaction with the
readahead tool (as noted in the technical docs for RHEL6) so I removed
that package entirely but the problem remains.
We have a slightly peculiar environment due to the config management
tool we use so I'm fairly confident this is our problem rather than a
bug in the auditd code. However, I'm struggling to debug why it is
failing each time. All I get back from the daemon is an exit code of
1, this seems to mean "generic or unspecified error", and no useful
error messages so I'm a bit stuck on what to do next.
Any suggestions?
Stephen Quinney
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
12 years, 10 months
[RFC] Virtual machine related events support
by Marcelo Cerri
Hi,
We are working on a project in which we need to get some events from
audit log related to virtual machine events and filter these events per
guests. Currently, the audit tools doesn't support this kind of search.
However we are willing to implement the necessary features to support it
and we'd like to receive some feedback from audit stakeholders on our
proposal.
Most of these records are generated by libvirt, but some of them are
generated by SELinux (as AVC denials). To get events generated by
libvirt, we'd like to search through audit records using the both "uuid"
and "vm" fields.
The following records are examples of both types of records that we
intend to filter:
type=VIRT_RESOURCE msg=audit(1319602467.134:33): user pid=14103 uid=0
auid=4294967295 ses=4294967295 msg='resrc=disk reason=start
vm="CentOS-Guest" uuid=41ffecd5-037e-0059-b074-ab2bf354fd0a old-disk="?"
new-disk="/var/lib/libvirt/images/CentOS-Guest.img":
exe="/usr/sbin/libvirtd" (hostname=?, addr=?, terminal=? res=success)'
type=AVC msg=audit(1318529059.690:801): avc: denied { read } for
pid=31199 comm="qemu-kvm" name="RHEL6.img" dev=dm-0 ino=524635
scontext=system_u:system_r:svirt_t:s0:c99,c999
tcontext=system_u:object_r:svirt_image_t:s0:c390,c835 tclass=file
While "vm" field contains the domain name and it's a more user friendly
identifier, it's intended to be a unique only within the scope of a
single host. On the other hand, "uuid" field is intended to be a global
identifier.
We'd like to create a stand-alone tool, similar to aulast, to filter
this kind of events and that could be part of audit's tools. It'd be
able to list VM specific events, and filter these events by UUID or VM
name if needed. We are intended to support the following usage/options
(any suggestions are welcome):
Usage: auvirt [ options ] [ uuid | vm-name ]
Options:
--summary(default)
Write a formatted output containing summarized information as
considered time period, total number of VM specific events,
total
number of events by type (start, stop, resource change) and
total
number of AVC events.
--raw
Write records related to guests as shown in audit.log. The
output may contain the following record types: VIRT_CONTROL,
VIRT_RESOURCE, VIRT_MACHINE_ID and AVC.
-f file, --stdin
Same as aulast.
We intend to correlate AVC denial events to guests through the security
label used by a guest in a specific period.
Another proposal would be change ausearch to support two new search
options:
-uu, --uuid vm-uuid
Search for an event with the given UUID.
-vm, --vm-name vm-name
Search for an event with the given virtual machine name.
However, these fields are defined by libvirt and it may be a good idea
to add to libaudit a new "audit_log_*" function to enforce a standard
message format for VM related events that could be used by other
virtualization tools.
Please, send your commentaries and suggestions.
Regards,
Marcelo Cerri
12 years, 11 months
filter specific file from specific program
by Lance Dillon
I have a need to filter a file from auditing, but only from a specific process.
We are running splunk, and indexing /var/log/audit/audit.log. We want audit.log
to be monitored, so we are using a dir watch on /var/log/audit, but we just
don't want splunk access to be reported. Filtering on obj_type doesn't work (-F
obj_type=auditd_log_t), because it filters everything, not that specific
process. However, it actually spawns another process to do the actual access,
so I can't filter on pid either. It runs unconfined, so I can't filter on
subj_type=unconfined_t, because that would filter way too much.
It was suggested to me to use audit roles. If this is something separate from
selinux context, perhaps someone can point me in the right direction? I only
want to filter out (not audit) access to audit.log from the specific process
/opt/splunkforwarder/bin/splunkd (and any forks it may do).
I've been looking at creating a separate selinux context for splunk, which will
do the trick, but is proving harder than I thought because it ends up forking
off other programs, like top and rpm and nptdate, that run under different
contexts than splunk (unconfined_t, rpm_t, and ntpdate_t respectively), so being
confined to a splunk_t type prevents those programs from running properly.
If anybody has any idea, or can point me in the right direction, i would
appreciate it.
Thanks
12 years, 11 months
Auditing only system admin commands and argument
by praveen.m.s＠accenture.com
Hi All,
Can some body please help me to get the audit rule syntax for , Auditing only system admin commands and arguments .
Regards,
Praveen
________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________
www.accenture.com
12 years, 11 months
FW: I'd like to turn auditd off but...
by Worsham, Michael
If you have figured out a way to exclude logging via a User or UID, please post it. Our Oracle OEM and VMware Tools daemons just spit out so much information it's unreal.
As for your earlier question about the large audit.log files, we have this line in our /etc/audit/auditd.conf file:
max_log_file_action = ROTATE
-- Michael
________________________________
CONFIDENTIALITY NOTICE: This email constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named recipient(s) intended by the sender of this message. This email, and any attachments, may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, any copying, using, disclosing or distributing to others the information in this email and attachments is STRICTLY PROHIBITED. If you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts or hard copies of the email and attachments.
EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
12 years, 11 months
