event loss with dispatcher?
by Klaus Heinrich Kiwi
Hi,
I'm trying to debug a potential problem with the dispatcher mechanism
in version 1.6.2. Long story short, I saw that some records were being
missed in the remote system (using the audisp-racf plugin), couldn't
find anything wrong with the code, so I enabled the syslog plugin,
trying to match the the syslog with the audit log output - At least in
my system, they are not matching.
In cases where there are more than one record per event, (eg. SYSCALL,
CWD, PATH), the majority of times only the syscall record is sent to the
syslog.. in rare cases I could see the path or the cwd record as well.
The impression that this would be a timing issue increased when I tried
to debug the daemon itself, placing a breakpoint in the
distribute_event() and/or dispatch_event() functions - in that case, I
could see all records going through, both in the execution path as in
the syslog.
Later also placed some debugging hooks in the process_inbound_event() in
the dispatcher code, and saw that records were already missing at that
point.
The lossy/lossless setting for the dispatcher queue doesn't appear to
affect this behavior. My tests involves a filesystem watch - when
triggered, only 3 records are generated (so not anywhere near the 128K
buffer size)
My env: RHEL 5 GA on s390x (sorry - no other box available for testing
at this time) with audit 1.6.2 (built from src.rpm as downloaded from
Steve's website).
Steve, btw, can you hold the audisp-racf merge a little bit? Found some
issues with selinux policy, the mapping to the remote system and believe
it or not, the plugin name itself :(
Thanks,
-Klaus Kiwi
16 years, 10 months
auditing for RHEL ES4
by Bill Tangren
I'm running RHEL ES 4 servers, and am having difficulty with aureport. I'm
using audit version 1.0.15-3, the one that comes with the OS. The problem
is that I need daily reports, and it is not doing it. The reports always
cover the entire range of available logs (sometimes gigabytes of data).
The reports can take a LONG time to compile, and it doesn't give me the
daily snapshot I need. I'm thinking of installing the latest tarball and
compiling, as I understand more recent versions of aureport have
implemented time limits. [I've emailed this list before about this.]
My question now is, is it possible to uninstall the prepackaged audit and
audit-lib, and install the latest from source, without seriously hosing my
system?
TIA,
--
Bill Tangren
U.S. Naval Observatory
16 years, 10 months
Re: [PATCH] XFRM: SPD auditing fix to include the netmask/prefix-length
by Paul Moore
On Thursday 29 November 2007 5:34:59 am Herbert Xu wrote:
> On Mon, Nov 26, 2007 at 07:55:12PM +0000, Paul Moore wrote:
> > Currently the netmask/prefix-length of an IPsec SPD entry is not included
> > in any of the SPD related audit messages. This can cause a problem when
> > the audit log is examined as the netmask/prefix-length is vital in
> > determining what network traffic is affected by a particular SPD entry.
> > This patch fixes this problem by adding two additional fields,
> > "src_prefixlen" and "dst_prefixlen", to the SPD audit messages to
> > indicate the source and destination netmasks. These new fields are only
> > included in the audit message when the netmask/prefix-length is less than
> > the address length, i.e. the SPD entry applies to a network address and
> > not a host address.
>
> Any reason why we don't just always include them?
The audit folks seem to be very sensitive to the size/length of the audit
messages, they prefer they be as small as possible. I thought that one way
to save space would be to only print the prefix length information when the
address referred to a network and not a single host.
Would you prefer it if the prefix length information was always included in
the audit message? Joy? Audit folks?
--
paul moore
linux security @ hp
16 years, 11 months
[PATCH] XFRM: SPD auditing fix to include the netmask/prefix-length
by Paul Moore
Currently the netmask/prefix-length of an IPsec SPD entry is not included in
any of the SPD related audit messages. This can cause a problem when the
audit log is examined as the netmask/prefix-length is vital in determining
what network traffic is affected by a particular SPD entry. This patch fixes
this problem by adding two additional fields, "src_prefixlen" and
"dst_prefixlen", to the SPD audit messages to indicate the source and
destination netmasks. These new fields are only included in the audit message
when the netmask/prefix-length is less than the address length, i.e. the SPD
entry applies to a network address and not a host address.
Example audit message:
type=UNKNOWN[1415] msg=audit(1196105849.752:25): auid=0 \
subj=root:system_r:unconfined_t:s0-s0:c0.c1023 op=SPD-add res=1 \
src=192.168.0.0 src_prefixlen=24 dst=192.168.1.0 dst_prefixlen=24
In addition, this patch also fixes a few other things in the
xfrm_audit_common_policyinfo() function. The IPv4 string formatting was
converted to use the standard NIPQUAD_FMT constant, the memcpy() was removed
from the IPv6 code path and replaced with a typecast (the memcpy() was acting
as a slow, implicit typecast anyway), and two local variables were created to
make referencing the XFRM security context and selector information cleaner.
Signed-off-by: Paul Moore <paul.moore(a)hp.com>
---
net/xfrm/xfrm_policy.c | 44 ++++++++++++++++++++++++++------------------
1 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b702bd8..bd70d79 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -2123,29 +2123,37 @@ void __init xfrm_init(void)
static inline void xfrm_audit_common_policyinfo(struct xfrm_policy *xp,
struct audit_buffer *audit_buf)
{
- if (xp->security)
+ struct xfrm_sec_ctx *ctx = xp->security;
+ struct xfrm_selector *sel = &xp->selector;
+
+ if (ctx)
audit_log_format(audit_buf, " sec_alg=%u sec_doi=%u sec_obj=%s",
- xp->security->ctx_alg, xp->security->ctx_doi,
- xp->security->ctx_str);
+ ctx->ctx_alg, ctx->ctx_doi, ctx->ctx_str);
- switch(xp->selector.family) {
+ switch(sel->family) {
case AF_INET:
- audit_log_format(audit_buf, " src=%u.%u.%u.%u dst=%u.%u.%u.%u",
- NIPQUAD(xp->selector.saddr.a4),
- NIPQUAD(xp->selector.daddr.a4));
+ audit_log_format(audit_buf, " src=" NIPQUAD_FMT,
+ NIPQUAD(sel->saddr.a4));
+ if (sel->prefixlen_s != 32)
+ audit_log_format(audit_buf, " src_prefixlen=%d",
+ sel->prefixlen_s);
+ audit_log_format(audit_buf, " dst=" NIPQUAD_FMT,
+ NIPQUAD(sel->daddr.a4));
+ if (sel->prefixlen_d != 32)
+ audit_log_format(audit_buf, " dst_prefixlen=%d",
+ sel->prefixlen_d);
break;
case AF_INET6:
- {
- struct in6_addr saddr6, daddr6;
-
- memcpy(&saddr6, xp->selector.saddr.a6,
- sizeof(struct in6_addr));
- memcpy(&daddr6, xp->selector.daddr.a6,
- sizeof(struct in6_addr));
- audit_log_format(audit_buf,
- " src=" NIP6_FMT " dst=" NIP6_FMT,
- NIP6(saddr6), NIP6(daddr6));
- }
+ audit_log_format(audit_buf, " src=" NIP6_FMT,
+ NIP6(*(struct in6_addr *)sel->saddr.a6));
+ if (sel->prefixlen_s != 128)
+ audit_log_format(audit_buf, " src_prefixlen=%d",
+ sel->prefixlen_s);
+ audit_log_format(audit_buf, " dst=" NIP6_FMT,
+ NIP6(*(struct in6_addr *)sel->daddr.a6));
+ if (sel->prefixlen_d != 128)
+ audit_log_format(audit_buf, " dst_prefixlen=%d",
+ sel->prefixlen_d);
break;
}
}
16 years, 11 months
Re: Missing audit information in xfrm_audit_common_policyinfo()?
by Paul Moore
On Monday 26 November 2007 11:47:09 am Joy Latten wrote:
> Paul Moore <paul.moore(a)hp.com> wrote on 11/21/2007 03:34:31 PM:
> > I just noticed that the IPsec auditing code does not appear to audit the
> >
> > netmask for the selector source and destination addresses in
> > xfrm_audit_common_policyinfo(). Before I threw a patch together I
>
> thought I
>
> > would check to see if there was a reason for this that I am missing ...
>
> I don't think we ever discussed including netmask when we added the
> ipsec audit info...
Hmmm ... okay. I'm almost certain it should be included when auditing changes
to the SPD as the netmask/prefixlen is very important when considering which
traffic will be matched by a particular SPD entry.
I'm working on a patch now.
--
paul moore
linux security @ hp
16 years, 11 months
[RFC PATCH] New audit message for NetLabel static/fallback labels
by Paul Moore
Those of you who follow the SELinux and/or LSM mailing lists know there is
work currently underway to provide static or fallback network peer labels for
use when traditional labeled networking (CIPSO or Labeled IPsec) is not
present. For the same reasons that NetLabel or Labeled IPsec configuration
changes are considered "auditable events", configuring the static/fallback
labels should likely be treated as an auditable event as well.
The patch below is part of a larger patchset which contains this new
functionality which has already been posted many times to the SELinux and LSM
lists. Those interested in the patchset are encouraged to look into the
archives of those mailing lists or check out the git tree here:
* git://git.infradead.org/users/pcmoore/lblnet-2.6_testing
I'm posting this patch to the audit list for comments/review as it contains
all of the audit related changes and I'd like to sort out any issues the
audit community may have sooner rather than later. Please take a few minutes
to look over the changes, most importantly the new message types and either
send me mail or preferably send mail straight to the audit list.
For reference, here are four examples of the new message types pulled from a
Fedora Rawhide machine running this patch:
* adding new fallback label using network interface "lo" and
address "127.0.0.0/8"
type=UNKNOWN[1416] msg=audit(1195671777.849:32): netlabel: \
auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 \
netif=lo daddr=127.0.0.0 daddr_mask=8 \
sec_obj=system_u:object_r:unlabeled_t:s0 res=1
* adding new fallback label using the default network interface and
address "192.168.0.10"
type=UNKNOWN[1416] msg=audit(1195671794.556:33): netlabel: \
auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 \
daddr=192.168.0.10 \
sec_obj=system_u:object_r:unlabeled_t:s0 res=1
* deleting the configuration for network interface "lo" and
address "127.0.0.0/8"
type=UNKNOWN[1417] msg=audit(1195671962.670:42): netlabel: \
auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 \
netif=lo daddr=127.0.0.0 daddr_mask=8 \
sec_obj=system_u:object_r:unlabeled_t:s0 res=1
* deleting the configuration for the defaul network interface and
address "192.168.0.10"
type=UNKNOWN[1417] msg=audit(1195671983.994:43): netlabel: \
auid=0 subj=root:system_r:unconfined_t:s0-s0:c0.c1023 \
daddr=192.168.0.10 \
sec_obj=system_u:object_r:unlabeled_t:s0 res=1
--
paul moore
linux security @ hp
16 years, 11 months
Missing audit information in xfrm_audit_common_policyinfo()?
by Paul Moore
I just noticed that the IPsec auditing code does not appear to audit the
netmask for the selector source and destination addresses in
xfrm_audit_common_policyinfo(). Before I threw a patch together I thought I
would check to see if there was a reason for this that I am missing ...
--
paul moore
linux security @ hp
16 years, 11 months
Re: auditd fails to start on FC6 system, newer kernels effect?
by Stephen Smalley
On Sat, 2007-11-17 at 04:31 -0500, Gene Heskett wrote:
> Greetings;
>
> FC6 system, uptodate, kernel 2.6.24-rc3, but this has existed since I
> re-enabled selinux in permissive mode just to see what complained.
>
> The manpage says to use the -f option for foreground troubleshooting, so here
> goes:
>
> [root@coyote linux-2.6.24-rc3]# man auditd
> [root@coyote linux-2.6.24-rc3]# which auditd
> /sbin/auditd
> [root@coyote linux-2.6.24-rc3]# auditd -f
> Config file /etc/audit/auditd.conf opened for parsing
> log_file_parser called with: /var/log/audit/audit.log
> log_format_parser called with: RAW
> priority_boost_parser called with: 3
> flush_parser called with: INCREMENTAL
> freq_parser called with: 20
> num_logs_parser called with: 4
> dispatch_parser called with: /sbin/audispd
> qos_parser called with: lossy
> max_log_size_parser called with: 5
> max_log_size_action_parser called with: ROTATE
> space_left_parser called with: 75
> space_action_parser called with: SYSLOG
> action_mail_acct_parser called with: root
> admin_space_left_parser called with: 50
> admin_space_left_action_parser called with: SUSPEND
> disk_full_action_parser called with: SUSPEND
> disk_error_action_parser called with: SUSPEND
> Started dispatcher: /sbin/audispd pid: 7828
> type=DAEMON_START msg=audit(1195291550.719:1106) auditd start, ver=1.4.2,
> format=raw, auid=4294967295 pid=7824 res=success, auditd pid=7824
> config_manager init complete
> Error setting audit daemon pid (Connection refused)
> type=DAEMON_ABORT msg=audit(1195291550.720:1107) auditd error halt,
> auid=4294967295 pid=7824 res=failed, auditd pid=7824
> Unable to set audit pid, exiting
> The audit daemon is exiting.
> Error setting audit daemon pid (Connection refused)
> [root@coyote linux-2.6.24-rc3]#
>
> Connection refused sounds as if something else isn't running that should be,
> but no direct clue, so what else needs to run too, before auditd?
More of a question for linux-audit (cc'd). Offhand, I'd guess that the
ECONNREFUSED is coming from the netlink code, but I don't know why.
Running it under strace might be illuminating.
--
Stephen Smalley
National Security Agency
16 years, 11 months
the meaning of this audit entry
by Bill Tangren
I'd like to know what this audit log entry means:
type=SYSCALL msg=audit(1195506796.447:7712726): arch=40000003 syscall=3
success=no exit=-11 a0=17 a1=a6c5b80 a2=1000 a3=a6c4d90 items=0 pid=3618
auid=825305204 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="X" exe="/usr/X11R6/bin/Xorg"
It appears that there is a problem with /usr/X11R6/bin/Xorg, and it is
issuing a failed syscall. I can tell you that I see this if there is a
user logged into the console GUI.
The following are the rules that I have that are auditing syscalls:
-a exit,always -S mknod -S acct -S swapon -S sethostname -F success=0 -F
auid=-1 -F auid=0
-a exit,always -S mknod -S acct -S swapon -S sethostname -F success=1
-a exit,always -S settimeofday -S adjtimex -S nfsservctl -S umount2 -S
fdatasync -S setdomainname -F success=0 -F auid=-1 -F auid=0
-a exit,always -S settimeofday -S adjtimex -S nfsservctl -S umount2 -S
fdatasync -S setdomainname -F success=1 -F auid=-1 -F auid=0
-a exit,always -S quotactl -S mount -S kill -S chroot -F success=0 -F
auid=-1 -F auid=0
-a exit,always -S quotactl -S mount -S kill -S chroot -F success=1 -F
auid=-1 -F auid=0
Is this being audited by default, or are one of the previous rules
auditing it?
Thanks!
--
Bill Tangren
U.S. Naval Observatory
16 years, 11 months
[PATCH] ausearch improvements
by Miloslav Trmac
Hello,
the attached patch adds some functionality to ausearch. It consists of
two main parts:
ausearch_add_interpreted_item() behaves like ausearch_add_item(), but
the conditions are evaluated by comparing the interpreted field value,
not the raw value (e.g. ("uid", "=", "mitr") instead of ("uid", "=",
"500"). In principle, the application using ausearch could contain it's
own code to "un-interpret" field values, but I think it is cleaner when
the only place that maps raw and interpreted value is libauparse. The
current implementation simply interprets the value of each field before
performing the comparison; in the future, the implementation could be
changed to "un-interpret" the supplied value when creating the rule if
the current implementation turns out to be too slow.
ausearch_add_timestamp_item() allows placing conditions on event
timestamp.
In addition, the patch fixes checking whether the operator is unknown in
ausearch_add_item().
Mirek
16 years, 11 months