auditing kdbus service names
by Paul Moore
Hello all,
I'm currently working on a set of LSM hooks for the new kdbus IPC mechanism
and one of the things that I believe we will need to add is a new audit field
for the kdbus service name (very similar to the old fashioned dbus service
name). I was thinking "kdbus_svc" for the field name, any objections?
--
paul moore
security @ redhat
9 years, 11 months
Filtering audit events
by rshaw1＠umbc.edu
I'm trying to figure out a way to filter a large number of events similar
to the following:
time->Mon Aug 31 08:08:26 2015
type=PATH msg=audit(1441022906.019:52947542): item=1 name=(null) inode=133
dev=fd:06 mode=0100640 ouid=0 ogid=9002 rdev=00:00
obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
type=PATH msg=audit(1441022906.019:52947542): item=0
name="/var/log/simpana/Log_Files/locks/" inode=92 dev=fd:06 mode=040775
ouid=0 ogid=9002 rdev=00:00 obj=system_u:object_r:var_log_t:s0
nametype=PARENT
type=CWD msg=audit(1441022906.019:52947542): cwd="/opt/simpana"
type=SYSCALL msg=audit(1441022906.019:52947542): arch=c000003e syscall=2
success=no exit=-13 a0=996d68 a1=42 a2=1b6 a3=0 items=2 ppid=11855
pid=15755 auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002 tty=(none) ses=125779 comm="clBackup"
exe="/opt/simpana/iDataAgent/clBackup" subj=system_u:system_r:initrc_t:s0
key="access"
The STIG-compliant audit ruleset we're using seems to generate a lot of
these, and I'm concerned that may be affecting the performance of the app
in question (also, I consider it log spam). I tried the following rule
(plus a few variations like ogid), but it doesn't seem to be working:
-a exit,never -F gid=9002 -k exclude
What would be the best way to approach this? I have a few other apps with
similar issues.
Thanks,
--Ray
10 years
Audit class/lab
by Steve Grubb
Hello,
I normally don't put the word out about speeches I give, or things like that.
But I am going to be teaching a hands-on audit class to demonstrate how to
configure, setup rules, and do searching and reporting using the native linux
audit tools.
The lab will be part of the Defence in Depth conference in Washington (Tyson's
Cormers, VA) on Sept 1. Its free, you just have to register. More info:
http://www.redhat.com/en/about/events/2015-defense-depth
I will be going over new features that aids insider threat detection and signs
of intrusion in addition to basics. Bring your questions and problems, let's
talk.
-Steve
10 years
Need help with understanding auditd rules
by Michael C Mc Quaid
Good Morning,
I don't know if this is an appropriate use of this group email, but after days and days of trying, we are not able to fix the auditing problem we are having, and we're desperate for help.
We need to audit our system to meet new security standards, which we have been able to do via the audit.rules file on our RHEL 5&6 nodes. However, we also have to run the hp-health packages on our systems to remotely monitor our systems with HP Insight Manager. When we run the hp-health processes, our auditd logs go from ~1000 entries to ~35,000 entries (every 10min), which is causing a problem in moving our audit logs to our storage system.
We have set up rules to "never" audit the hp-health processes themselves, but this does not fix the problem. It only reduces the amount of entries by ~10,000. It seems that the hp-ilo module loaded in the kernel is running system "checks" at a very rapid pace and is reporting them to the hp-snmp-agent processes (which are the ones we have set up never audit rules for). We don't know how to set up a rule to eliminate the monitoring of these ilo activities (which are a combination chmods/touches/opens/execves/etc.), while continuing to monitor these syscalls for the rest of the system.
Are you aware of anyone else who has run into this problem, or is there a thread on your web-page we can look at (we looked, but could not find anything). We are looking for a way to set up a rule to not monitor any of the Insight Manager activity but still maintain the capability to monitor all of our other syscalls.
Thanks in advance for your help.
Mike McQuaid.
10 years
Re: Failure flag "0" doesn't work
by Burn Alting
Alex,
This is a little outside my experience.
One assumes the audit_failure variable has been set in the kernel
(kernel/audit.c). Perhaps you can test this.
Given you can get a copy of the kernel source you are running, perhaps
trace through what's happening. Using the messages
before/during/directly after the death of auditd, and what's routing to
dmesg, perhaps you can reverse engineer what is happening.
Perhaps someone else on the list can explain why, given -f is set to 0,
and the kernel has no user space destination for audit, it still prints
(via printk()?)
Regards
On Thu, 2015-08-20 at 13:17 +0300, Alex Beljanski wrote:
> We have custom audit-dispatcher for process events. On some servers
> when auditd fails, all audit messages writes to kernel.
> We don't want to see all this messages in dmesg and set failure flag
> to "0". This doesn't help.
>
>
> # cat /etc/audit/auditd.conf
>
> log_file = /var/log/audit/audit.log
> log_format = NOLOG
> log_group = root
> priority_boost = 4
> flush = none
> num_logs = 1
> disp_qos = lossy
> dispatcher = /sbin/audit-dispatcher
> name_format = none
> max_log_file = 1
> max_log_file_action = keep_logs
> space_left = 75
> space_left_action = ignore
> admin_space_left = 50
> admin_space_left_action = ignore
> disk_full_action = ignore
> disk_error_action = ignore
> enable_krb5 = no
>
> cat /etc/audit/rules.d/audit.rules
>
> -D
>
> -b 8192
>
> -f 0
> -e 1
>
> -a exit,always -F arch=b32 -S 11 -k exec32
> -a exit,always -F arch=b64 -S 59 -k exec64
>
>
>
>
> 2015-08-20 12:39 GMT+03:00 Burn Alting <burn(a)swtf.dyndns.org>:
> Alex,
>
> Can you provide a little more detail?
>
> Perhaps your /etc/audit/auditd.conf, /etc/audit/rules.d/*,
> your test
> case, the expected outcome and the outcome you actually get.
>
> Regards
>
> On Thu, 2015-08-20 at 11:09 +0300, Alex Beljanski wrote:
> > Hi!
> >
> >
> > We have problem in CentOS 7 with auditd.
> >
> > For our servers we set failure flag 0, but kernel write
> messages and
> > we see them in dmesg.
> >
> > uname -a
> > Linux 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18
> UTC 2015
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > # rpm -qa | grep audit
> > audit-2.4.1-5.el7.x86_64
> >
> >
> > Why this doesn't work?
> >
> >
> >
> >
> >
>
> > --
> > Linux-audit mailing list
> > Linux-audit(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
>
10 years, 1 month
User Login Lifecycle events
by Steve Grubb
Hello,
I am looking for feedback and comments on a new document that I just finished
that outlines the expectations of audit logging around user sessions.
http://people.redhat.com/sgrubb/audit/user-login-lifecycle.txt
My hope is that we can get a test suite developed that follows this to verify
that applications are doing it right and consistently. This will also allow
third party's to write analysis software since there is a published standard.
Thanks,
-Steve
10 years, 1 month
Failure flag "0" doesn't work
by Alex Beljanski
Hi!
We have problem in CentOS 7 with auditd.
For our servers we set failure flag 0, but kernel write messages and we see
them in dmesg.
uname -a
Linux 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux
# rpm -qa | grep audit
audit-2.4.1-5.el7.x86_64
Why this doesn't work?
10 years, 1 month
audit 2.4.4 released
by Steve Grubb
Hello,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- Fix linked list correctness in ausearch/report
- Add more cross compile fixups (Clayton Shotwell)
- Update auparse python bindings
- Update libev to 4.20
- Fix CVE-2015-5186 Audit: log terminal emulator escape sequences handling
The main thing to discuss in this release is the CVE. The issue is that the
audit logs handle untrusted data. We know that and hex encode anything that
has control characters. Turns out that running ausearch or report with the -i
argument simply decoded the control characters. To see what I mean, consider
the following log entry:
type=PATH msg=audit(1438371086.399:1711): item=1
name=1B5B346D756E6465726C696E6564 inode=14495887363 dev=09:7e mode=0100640
ouid=4325 ogid=4325 rdev=00:00 obj=unconfined_u:object_r:user_home_t:s0
nametype=NORMAL
type=CWD msg=audit(1438371086.399:1711): cwd="/home/sgrubb/test/underlined"
type=SYSCALL msg=audit(1438371086.399:1711): arch=c000003e syscall=2
success=yes exit=3 a0=7fff24f2a6f0 a1=42 a2=1a0 a3=691 items=2 ppid=18629
pid=19011 auid=4325 uid=4325 gid=4325 euid=4325 suid=4325 fsuid=4325 egid=4325
sgid=4325 fsgid=4325 tty=pts4 ses=1 comm="test"
exe="/home/sgrubb/test/underlined/test"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="underlined"
If you ausearch -i on that file, your screen will get underlines with all the
text. An attacker could change this to be worse than just underlining your
text. They could try to write to the window title and then bounce that back in
black on black text to the command prompt hoping the admin will press enter.
I did a survey recently and all emulators I could find on Fedora 22 do not
honor the window title fetching command. There was a discussion about it on
oss-security list as preparation for this announcement. Read the thread here:
http://www.openwall.com/lists/oss-security/2015/08/11/8
Please let me know if you run across any problems with this release.
-Steve
10 years, 1 month
