Excluding the single executable on the top of audit.rules
by Исаев Виталий Анатольевич
Hello all,
I would like to ask for an explanation about making my audit.rules proper. What am I trying to do is to exclude all the syscall events coming from exe="/usr/bin/pulseaudio" and its components. At the moment about 95% of audit log is filled with messages related to pulseaudio:
# aureport -x -if my.log --summary
Executable Summary Report
=================================
total file
=================================
1156923 /usr/bin/pulseaudio
191719 /usr/libexec/pulse/gconf-helper
49282 /usr/bin/gnome-volume-control-applet
8035 /usr/libexec/gnome-settings-daemon
1045 /usr/sbin/crond
265 /usr/bin/nautilus
23 /usr/sbin/sshd
Please look through the current version of audit.rules. How should I modify them?
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320
# Feel free to add below this line. See auditctl man page
#-a exit,never -F exe=/usr/bin/pulseaudio -S open
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S open
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S execve
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S fork
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S vfork
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S exit
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S exit_group
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S getdents
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S chmod
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S fchmod
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S fchmodat
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S chown
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S fchown
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S lchown
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S fchownat
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S unlink
-a exit,always -F arch=x86_64 -F uid>=500 -F gid>=500 -F ppid!=1 -F auid!=429496729 -S unlinkat
P.S. We're using RHEL 6.4 with audit-2.2-2.el6.x86_64.
Sincerely,
Vitaly Isaev
Software engineer
Information security department
Fintech JSC, Moscow, Russia
10 years, 4 months
[PATCH] arm64: audit: Fix build for audit changes
by Mark Brown
From: Mark Brown <broonie(a)linaro.org>
Commit 3efe33f5d2 (audit: x86: drop arch from __audit_syscall_entry()
interface) removed the arch parameter from __audit_syscall_entry() and
updated the only current user in mainline but this breaks the ARMv8 audit
code that has been added in -next. Fix this by making the equivalent
update to ARMv8.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
Now -rc1 is out this should be applied to the audit tree (or squashed
into the commit above) - the arm64 audit support is in mainline now and
-next is failing to build arm64 due to this.
arch/arm64/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 0310811..159251f 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1116,8 +1116,8 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
trace_sys_enter(regs, regs->syscallno);
#ifdef CONFIG_AUDITSYSCALL
- audit_syscall_entry(syscall_get_arch(), regs->syscallno,
- regs->orig_x0, regs->regs[1], regs->regs[2], regs->regs[3]);
+ audit_syscall_entry(regs->syscallno, regs->orig_x0, regs->regs[1],
+ regs->regs[2], regs->regs[3]);
#endif
return regs->syscallno;
--
2.1.0.rc1
10 years, 4 months
Re: Backlog exceeded when using audisp
by Andy Ruch
> On Wednesday, August 13, 2014 02:37:52 PM Andy Ruch wrote:
> > I'm trying to send the audit logs on a secure RHEL 6.5 system to rsyslog.
> > Rsyslog will then send them to another system for centralized collection.
>
> This is fine.
>
> > I can't have audisp send them directly because the connectivity is
> > unreliable and rsyslog provides on disk queues for reliable delivery.
>
> So does auditd. It doesn't lose events unless some limit was exceeded.
>
> > I've activated the syslogplugin of audisp to do the transfer. The problem is
> > getting the logs transferred fast enough. The system is configured to panic
> > upon error (-f 2), which it does frequently when I do something like update
> > the SELinux RPM since watching /etc/selinux is required by the STIG.
>
> A couple of thoughts here. Perhaps you want to have a policy where when you
> update selinux policy, you suspend auditing and then update and then resume.
> Short of that, you'll need to boost the priority and enlarge the queue sizes.
> The panic will only occur on an in-kernel buffer overflow. User space can't do
> that.
>
> > I have the audit buffer size configured to 8192 and the audisp queue set to
> > 120. I'm surprised the 8192 buffer is being overwhelmed. When I look at
> > aureport for just the time frame of the action, I get approximately 350
> > events. I know that each event may have multiple entries, but it is
> > interesting that the capacity of a buffer over 20 times bigger is being
> > exceeded.
>
> Well, if the auditspd buffer is full and you have lossless buffering, the daemon
> waits until there is room in the queue to continue processing and then the
> kernel buffer backs up. You have to have settings in user space that allow
> auditd to keep the kernel queue as empty as possible.
>
> >
> > Can anyone in a similar situation share any insights? Is there a faster way
> > to transfer the logs rather than the audispsyslogplugin? We use to have
> > rsyslog monitor the audit.log file but ran into some issues when we started
> > dealing with log file rollover. And it just seems cleaner to send the audit
> > logs directly.
>
> You can also just load rules via auditctl. The kernel defaults to sending
> events to syslog if auditd is not running.
>
> -Steve
Upon further testing, I think there might be something else as the root cause. For my testing, I'm adding an selinux user (semanage user -a ...). This will trigger a load_policy command for SELinux. When everything works fine, auditd processes roughly 2000 events and audisp handles this with no problems. However, sometimes when I run the command, auditd will receive over 15000 events. As far as I can tell, the extra events are all SELinux error events stating "selinux_audit_rule_match: stale rule". What would cause this and why does it not happen every time? Is this an audit issue or an SELinux issue?
10 years, 4 months
Backlog exceeded when using audisp
by Andy Ruch
Hello,
I'm trying to send the audit logs on a secure RHEL 6.5 system to rsyslog. Rsyslog will then send them to another system for centralized collection. I can't have audisp send them directly because the connectivity is unreliable and rsyslog provides on disk queues for reliable delivery. I've activated the syslogplugin of audisp to do the transfer. The problem is getting the logs transferred fast enough. The system is configured to panic upon error (-f 2), which it does frequently when I do something like update the SELinux RPM since watching /etc/selinux is required by the STIG.
I have the audit buffer size configured to 8192 and the audisp queue set to 120. I'm surprised the 8192 buffer is being overwhelmed. When I look at aureport for just the time frame of the action, I get approximately 350 events. I know that each event may have multiple entries, but it is interesting that the capacity of a buffer over 20 times bigger is being exceeded.
Can anyone in a similar situation share any insights? Is there a faster way to transfer the logs rather than the audispsyslogplugin? We use to have rsyslog monitor the audit.log file but ran into some issues when we started dealing with log file rollover. And it just seems cleaner to send the audit logs directly.
Thanks,
Andrew Ruch
10 years, 4 months
[PATCH] arm64: audit: Fix build for audit changes
by Mark Brown
From: Mark Brown <broonie(a)linaro.org>
Commit 3efe33f5d2 (audit: x86: drop arch from __audit_syscall_entry()
interface) removed the arch parameter from __audit_syscall_entry() and
updated the only current user in mainline but this breaks the ARMv8 audit
code that has been added in -next. Fix this by making the equivalent
update to ARMv8.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 70526cfda056..310842e3d477 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1115,8 +1115,8 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
trace_sys_enter(regs, regs->syscallno);
- audit_syscall_entry(syscall_get_arch(), regs->syscallno,
- regs->orig_x0, regs->regs[1], regs->regs[2], regs->regs[3]);
+ audit_syscall_entry(regs->syscallno, regs->orig_x0, regs->regs[1],
+ regs->regs[2], regs->regs[3]);
return regs->syscallno;
}
--
2.0.1
10 years, 4 months
Fw: How to define rule for SERVICE_START/STOP?
by Gisela Cheng
So I understand the SERVICE_START/STOP are sent by systemd. We do have a
unit file for systemd as following:
[Unit]
Description=......
[Service]
Type=forking
WorkingDirectory=/var/lib/....
PIDFile=/var/run/xxxx.pid
ExecStart=/usr/sbin/xxxx
Restart=always
# Wait a bit before restarting xxx
RestartSec=5s
# xxxx kicks the watchdog
WatchdogSec=60
# If xxxx doesn't signal that it's ready, consider it failed
TimeoutStartSec=300
# Time between SIGTERM and SIGKILL on shutdown
TimeoutStopSec=20
# Allows calls to sd_notify from main process
NotifyAccess=main
StandardInput=null
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Would this trigger the creation of the audit record? Our application is
expected to be up and running all the time. But we can shut it down, or
it could be down due to error. We want audit record when it is down.
Would TimeoutStopSec= tag (don't know if this is the proper name)
does it, or I need other special tag?
Thanks.
Gisela Cheng
giselac(a)us.ibm.com
----- Forwarded by Gisela Cheng/Poughkeepsie/IBM on 08/05/2014 09:24 AM
-----
From: Steve Grubb <sgrubb(a)redhat.com>
To: linux-audit(a)redhat.com
Cc: Gisela Cheng/Poughkeepsie/IBM@IBMUS
Date: 08/04/2014 04:34 PM
Subject: Re: How to define rule for SERVICE_START/STOP?
On Monday, August 04, 2014 03:16:18 PM Gisela Cheng wrote:
> We want to use Linux audit type SERVICE_START/STOP for our application
> running as service.
> But I am not able to find example on how to use auditctl to define the
> rule. It seems to me that all the examples are of rules defined for
> system_calls.
There are 2 kinds of events. Some are hardwired into the applications (or
kernel) and they send them if auditing is enabled. The other kind are
discretionary in that the admin defines what to audit. The problem with
the
discretionary rules are that it is from the kernel's point of view.
Meaning
that you only get events as the process transitions through something the
kernel controls like files or syscalls.
> Questions:
> 1. Can I use audit type SERVICE_START/STOP for my application runs as
> service?
The SERVICE_START/STOP command are intended to be sent by the init daemon.
Systemd already sends these. Upstart could be patched, but if that is done
it
would need to match the layout, order, and formatting of the systemd
events.
> or would it be considered as type USR_CMD?
USER_CMD is for something like sudo to record what command the user will
be
running.
> 2. How do I use auditctl to define rule for SERVICE_START/STOP? Can
you
> direct/point me to URL/documentation where it is documented?
It can't define these events because the kernel only sees a process start
or
stop. It has no idea that its a service. Only init can tell the
difference.
-Steve
10 years, 4 months
How to define rule for SERVICE_START/STOP?
by Gisela Cheng
We want to use Linux audit type SERVICE_START/STOP for our application
running as service.
But I am not able to find example on how to use auditctl to define the
rule. It seems to me that
all the examples are of rules defined for system_calls. Questions:
1. Can I use audit type SERVICE_START/STOP for my application runs as
service? or would it
be considered as type USR_CMD?
2. How do I use auditctl to define rule for SERVICE_START/STOP? Can you
direct/point me
to URL/documentation where it is documented?
Thanks.
Gisela Cheng
giselac(a)us.ibm.com
10 years, 4 months
Can we audit writing to character device?
by Tetsuo Handa
Hello.
I tried to audit write syscall on /dev/watchdog in order to check
https://access.redhat.com/site/solutions/707563 .
I expected that I can do it using
# auditctl -a exit,always -F filetype=character -F devmajor=10 -F devminor=130 -F arch=b64 -S write -k watchdog
but it did not work (even
# auditctl -a exit,always -F filetype=character -F arch=b64 -S write -k watchdog
did not work).
Is this functionality not implemented?
Should I do
# stap -d hpwdt -e 'probe module("hpwdt").function("hpwdt_ping") { printf("%u\n", gettimeofday_ns()); }'
instead (if I can't use this functionality) ?
Regards.
10 years, 4 months
Re: RHEL 6 audit.rules question
by Dan White
On Jul 30, 2014, at 04:33 PM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> On Wednesday, July 30, 2014 08:21:45 PM Dan White wrote:
> > Does the system allow for the import/include of groups of rules in other
> > files - like logrotate and /etc/logrotate.d/* ?
>
> No, but in 2.3 and later there is a /etc/audit/rules.d/ directory where rules
> can be dropped off. The augenrules utility will "compile" those into a master
> audit.rules file. You also have to enable augenrules by setting
> USE_AUGENRULES="yes" in /etc/sysconfig/audit. that is about as close as it
> comes.
>
> -Steve
Thanks for the quick answer.
Any plans to release 2.3.x to RHEL 6 that can be shared ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes)
10 years, 4 months
