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, 3 months
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, 2 months
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, 6 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, 6 months
Suppress messages from /var/log/audit.log via audit.rules
by Worsham, Michael
Does anyone have an idea on how to suppress (exclude) these entries from showing up in the audit.log on a RHEL platform? I have tried the following to no success:
type=CWD msg=audit(1316431049.130:131982948): cwd="/"
type=PATH msg=audit(1316431049.130:131982948): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/x86_64/libc.so.6"
type=SYSCALL msg=audit(1316431049.130:131982949): arch=c000003e syscall=2 success=no exit=-2 a0=7fffacb237a0 a1=0 a2=2abb06288000 a3=6462696c2f343662 items=1 ppid=3921 pid=3923 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sed" exe="/bin/sed" subj=system_u:system_r:initrc_t:s0 key=(null)
type=CWD msg=audit(1316431049.130:131982949): cwd="/"
type=PATH msg=audit(1316431049.130:131982949): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/tls/libc.so.6"
type=SYSCALL msg=audit(1316431049.130:131982950): arch=c000003e syscall=2 success=no exit=-2 a0=7fffacb237a0 a1=0 a2=2abb06288000 a3=6462696c2f343662 items=1 ppid=3921 pid=3923 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sed" exe="/bin/sed" subj=system_u:system_r:initrc_t:s0 key=(null)
type=CWD msg=audit(1316431049.130:131982950): cwd="/"
type=PATH msg=audit(1316431049.130:131982950): item=0 name="/usr/lib/vmware-tools/lib64/libdnet.so.1/x86_64/libc.so.6"
type=SYSCALL msg=audit(1316431049.130:131982951): arch=c000003e syscall=2 success=no exit=-2 a0=7fffacb237a0 a1=0 a2=2abb06288000 a3=6462696c2f343662 items=1 ppid=3921 pid=3923 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sed" exe="/bin/sed" subj=system_u:system_r:initrc_t:s0 key=(null)
Packages installed:
redhat-release-5Server-5.7.0.3
audit-1.7.18-2.el5
selinux-policy-targeted-2.4.6-316.el5
Current rules:
## Suppress all VMware Tools system calls
-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT
-a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-ENOENT
-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-2
-a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-2
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe 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 of the email or 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.
13 years, 1 month
audit-1.8 released
by Steve Grubb
Hi,
I've just released a new version of the (old) audit daemon. It can be downloaded from
http://people.redhat.com/sgrubb/audit. The ChangeLog is:
- Performance improvements for ausearch/report
- Fix debug output resolving numeric address
- Fix spelling error in audit.rules (#667845)
- Improve warning in auditctl regarding immutable mode (#654883)
- In ausearch, allow searching for auid -1
- Fix memory leak in aureport
- Fix parsing state problem in libauparse
- Update prelude support
- Add new event types
- Update syscall tables
- On i386, audit rules do not work on inode's with a large number
- Improve the robustness of libaudit field encoding functions
- Add optional ARM processor support
- Fix autrace to use correct syscalls on i386 systems (Peng Haitao)
- In auparse, add ability to interpret session and capabilities
- Add ability for audispd syslog plugin to choose facility local0-7
- Report server issues to remote client
- Update ausearch parsing
- Update auparse to handle virt events
- Make audisp-remote robust
- Add 2 error returns to python bindings
- Update the man pages a little
- Add some debug info to audidp-remote startup and shutdown
- In auditd, if disk_error_action is ignore, limit syslog messages to 5
- Fix some memory leaks
This does not even really capture all the updates to this branch. This is intended to
be the final release of the 1.x series. This release backports everything I possibly
can from trunk to the old daemon. With all these fixes, its a big update. Please test
it if you use the 1.x series.
Please let me know if you run across any problems with this release.
-Steve
13 years, 2 months
IRC channel
by Tully Gray
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey,
does Linux audit have an IRC channel?
Tully Gray.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
iQIcBAEBAgAGBQJOqJdOAAoJEKNjRVNXXwT+/6MQAKu+SIfPXIH2CpaVnQa+S7zv
f7K0vydLbnYW/NDt9FOQ7osXHioc4ivDeyqPLitEmmlVnvhqRUfBZafV2WpcjNgO
sFpln+C5fQ5P84XdsOaCk/yUhgit1dj9kij6V90LcGidQsMf3bewLYaJCyeuOZpF
DXQdMpnUX6yY4wgTwEWGK79XizmrpcRRohJdMBj0lGkqz8YOjxqqMUc9F8UDnKY9
s/wOCsfwhwgo+8yZCrC9bo9EXJM7VeK+dBjqRKznDqWuiskbyrs/tT8H1tc0TZ4T
zrm56MlzwRrC7zT17Qmdr6fpSXR/5PVEbXgMu5KNPe3rhffXyG9VHsb72dZ12m2g
m9FVokyfz4pvQTZ7048a/j+hdNVp8nNLwdeBZQH97GZWp6AQf0f0QOozMEpD57mq
dw/2Qd9ooHB+2QM1ab9chQfWw4B8yGHLEhqi8FK9VaySf3L+oWfsNBhC3qrxz10l
gwzRbVMiwemVvv46QdG16RLh4g2AGkY/e+DPQSedqlDsUauZ7Aalj9Y4BKuQotct
hvCdAu9bVVBt8rAcmGEhMvKcDo14684dIvz4knHslE/ta5ZajovzNzzWpLp+SZTx
Wzb+xrr8kNy1mpfTU+HmPVszM4ZZxVD/+v1Am5qxmQgzp0crl02YNFOr1HRt+pxI
0fmPZ7ln5GnhUS9Wo4u/
=af0c
-----END PGP SIGNATURE-----
13 years, 2 months
question on syslog-ng and auditd
by larry.erdahl＠usbank.com
I want to send my auditd messages to our local log collector via
syslog-ng, what is the recommended why of doing this? Can I enter
syslog-ng as the dispatcher or do I need to first send the logs to disk
then read from the audit.log file. I have no reason to store these
messages on disk. This might be out of the realm of this group , but any
syslog-ng config recommendation would be appreciated.
As you can see from my question I'm a novice when it comes to auditd and
syslog-ng. I've read all resource materials found in
/usr/share/doc/packages/audit and googled a lot of good information and
have learned a great deal from monitoring this forum, but I'm still
struggling with auditd. Does anyone know if Redhat or anyone else offers
training for auditd or can you recommend any books that might help?
Thanks...
Larry E. Erdahl
Information Security Services
Computer Security Incident Response Team (CSIRT)
1 Meridian Crossing
Richfield, MN 55423
Mail Code: EP-MN-MS6I
Office Phone: (612)973-7153
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
---------------------------------------------------------------------
13 years, 2 months
