* Re: perhaps obvious question: auditd and setuid/setgid?
From: rshaw1 @ 2015-09-03 2:32 UTC (permalink / raw)
To: John Jasen; +Cc: linux-audit
In-Reply-To: <55E780DE.80400@gmail.com>
> I'm currently testing auditd with rules for setuid or setgid binaries on
> the system.
>
> I currently maintain the list via find, and pushing the results to a
> audit.rules file.
>
> I'm hoping there's a cleaner way, perhaps by triggering on the
> appropriate syscall -- but have not discovered it.
>
> Is there an easier method?
The find method is what I use (though I push it to a file in rules.d and
then run augenrules, which for RHEL5/6 I just stole from RHEL7). Using
find to generate these rules is actually in the text of, IIRC, at least
one of the RHEL STIGs (6, draft of 7, possibly both), though not quite as
automated as the way I do it.
--Ray
^ permalink raw reply
* Re: Filtering audit events
From: Steve Grubb @ 2015-09-02 23:31 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <84a967ab2e861435cc1d0c3553aef15f.squirrel@webmail.umbc.edu>
On Monday, August 31, 2015 09:58:42 AM rshaw1@umbc.edu wrote:
> > If you use the -i argument to ausearch, it becomes more clear what the
> > issue is. The problem is that the program is opening the file for read and
> > write, but the permissions are just for group read. If that file were
> > 0660, then you would not get this audit event.
>
> Hrm. The process is running as the root user, though. It's going over
> the whole filesystem (for backups).
But look at all the uids it has:
auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002
I'm betting it;s a setuid program and is being prevented by various checks.
Its effective uid is 4990, its fsuid is 4990. If changing the permissions is
acceptable and fixes its, that what I'd do.
-Steve
^ permalink raw reply
* perhaps obvious question: auditd and setuid/setgid?
From: John Jasen @ 2015-09-02 23:06 UTC (permalink / raw)
To: linux-audit
I'm currently testing auditd with rules for setuid or setgid binaries on
the system.
I currently maintain the list via find, and pushing the results to a
audit.rules file.
I'm hoping there's a cleaner way, perhaps by triggering on the
appropriate syscall -- but have not discovered it.
Is there an easier method?
^ permalink raw reply
* Re: CIS and audit rules
From: John Jasen @ 2015-09-02 23:01 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <23396023F719ED41888885C3B22D602F03714E@WPEXCH2010MR11.bur.hydro.qc.ca>
[-- Attachment #1.1: Type: text/plain, Size: 844 bytes --]
I've been testing a variant of the CIS benchmarks, supplemented (for
compliance reasons) by the NIST USGCB baselines.
I've also been testing auditd with setuid/setgid binaries.
Also as a potential replacement for aide (again, mostly compliance reasons).
Your use of auditd rules depends a lot on your drivers for doing so, and
your desired results.
On 08/28/2015 04:12 PM, Alarie, Maxime wrote:
>
>
>
> Anyone ever implemented auditd by following the CIS standards
> described here?
> https://benchmarks.cisecurity.org/downloads/show-single/?file=suse11.110
>
>
>
> Is it too restrictive? Not enough? Too much ressources consuming? I
> would like some comments/opinions if possible.
>
>
>
>
>
> Many thanks.
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[-- Attachment #1.2: Type: text/html, Size: 3639 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: List or description of auditd exit codes?
From: Steve Grubb @ 2015-09-02 21:56 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <23396023F719ED41888885C3B22D602F0384DE@WPEXCH2010MR11.bur.hydro.qc.ca>
On Tuesday, September 01, 2015 05:05:26 PM Alarie, Maxime wrote:
> I am looking for a list or a description of the exit codes generated by the
> audit daemon in audit.log Anyone know if such a lst exists??
Are we talking about the syscall exit codes or the audit daemon's exit code
which is not in the logs? If its the first, these are the normal exit codes
which typically reflect errno. Try 'man errno'.
-Steve
^ permalink raw reply
* List or description of auditd exit codes?
From: Alarie, Maxime @ 2015-09-01 17:05 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 173 bytes --]
Good day,
I am looking for a list or a description of the exit codes generated by the audit daemon in audit.log Anyone know if such a lst exists??
Many thanks.
[-- Attachment #1.2: Type: text/html, Size: 2860 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Audit class/lab
From: Steve Grubb @ 2015-08-31 14:15 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1604626.3lxFnqoXVB@x2>
On Wednesday, July 15, 2015 06:19:30 PM Steve Grubb wrote:
> 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.
For anyone attending the class tomorrow, I have a tarball with some rules for
you to install. These rules are not exactly what I'd suggest running with on a
daily basis, they are intended to cause different kinds of events that we'll
talk about. Please install them before the class so that you have events to
see.
http://people.redhat.com/sgrubb/files/lab.tar.gz
I'd also suggest using Fedora 22 or RHEL7 or any distribution that's recent.
If you can, I'd also suggest using the most recent audit package.
Thanks,
-Steve
^ permalink raw reply
* Re: Filtering audit events
From: rshaw1 @ 2015-08-31 13:58 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1315756444.19796884.1441027336015.JavaMail.zimbra@redhat.com>
> If you use the -i argument to ausearch, it becomes more clear what the
> issue is. The problem is that the program is opening the file for read and
> write, but the permissions are just for group read. If that file were
> 0660, then you would not get this audit event.
Hrm. The process is running as the root user, though. It's going over
the whole filesystem (for backups).
>>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
>
> This should work as long as its before the open rule. Rules are processed
> from top to bottom with first match winning.
>
>>What would be the best way to approach this?
It's pretty much at the top, well before the open rule. There are only
two other exclude rules before it, and the general settings:
-D
-b 8192
-f 1
This is on RHEL6, if that matters.
--Ray
^ permalink raw reply
* Re: Filtering audit events
From: Steven Grubb @ 2015-08-31 13:22 UTC (permalink / raw)
To: rshaw1; +Cc: linux-audit
In-Reply-To: <80528828ce7a24c2d9ed2e16b46f4fb6.squirrel@webmail.umbc.edu>
----- Original Message -----
>From: rshaw1@umbc.edu
>To: linux-audit@redhat.com
>Sent: Monday, August 31, 2015 8:18:12 AM
>Subject: Filtering audit events
>
>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"
If you use the -i argument to ausearch, it becomes more clear what the issue is. The problem is that the program is opening the file for read and write, but the permissions are just for group read. If that file were 0660, then you would not get this audit event.
>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
This should work as long as its before the open rule. Rules are processed from top to bottom with first match winning.
>What would be the best way to approach this?
Fix the permissions if possible?
-Steve
>I have a few other apps with similar issues.
^ permalink raw reply
* Filtering audit events
From: rshaw1 @ 2015-08-31 12:18 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply
* CIS and audit rules
From: Alarie, Maxime @ 2015-08-28 20:12 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 295 bytes --]
Anyone ever implemented auditd by following the CIS standards described here? https://benchmarks.cisecurity.org/downloads/show-single/?file=suse11.110
Is it too restrictive? Not enough? Too much ressources consuming? I would like some comments/opinions if possible.
Many thanks.
[-- Attachment #1.2: Type: text/html, Size: 2442 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Need help with understanding auditd rules
From: Steve Grubb @ 2015-08-28 12:48 UTC (permalink / raw)
To: linux-audit; +Cc: Michael C Mc Quaid
In-Reply-To: <OF7F3F36E6.CFDF8F52-ON86257EAF.0044C8AD-86257EAF.0044C8BC@mck.us.ray.com>
On Friday, August 28, 2015 07:31:18 AM Michael C Mc Quaid wrote:
> 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.
So...what's causing it?
ausearch --start today -k --raw | aureport --key --summary
aureport --start today --syscall --summary
aureport --start today --file --summary
> 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,
Yes, there are people that flood their system with events.
> 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.
Normally, the security rules are intended to be about what people do rather
than daemons. The difference between people and daemons is people have an auid
>= 500 and a daemon has an auid of -1. People have a session id > 0 and
daemons have -1. You might be able to fix your rules to not care about what
daemons do. For example, if you currently have:
-a always,exit -S open
you might change it to
-a always,exit -S open -F auid>=500 -F auid!=-1
The kernel uses unsigned numbers. This causes -1 to become 4294967295 which
is greater than 500.
-Steve
^ permalink raw reply
* Need help with understanding auditd rules
From: Michael C Mc Quaid @ 2015-08-28 12:31 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1630 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 1914 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Failure flag "0" doesn't work
From: Steve Grubb @ 2015-08-21 0:14 UTC (permalink / raw)
To: linux-audit, burn
In-Reply-To: <1440108941.26050.7.camel@swtf.swtf.dyndns.org>
On Friday, August 21, 2015 08:15:41 AM Burn Alting wrote:
> One assumes the audit_failure variable has been set in the kernel
> (kernel/audit.c). Perhaps you can test this.
Yes, that is where it gets written to.
> 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()?)
The explanation of what the failure flag does is explained in the auditctl man
pages:
"This option lets you determine how you want the kernel to handle critical
errors. Example conditions where this mode may have an effect includes:
transmission errors to userspace audit daemon, backlog limit exceeded, out
of kernel memory, and rate limit exceeded."
Note that dead audit daemon is not included in what it covers.
> 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.
This is expected when the audit system is enabled.
> > We don't want to see all this messages in dmesg and set failure flag
> > to "0". This doesn't help.
Correct. For _events_ to not be written to syslog, the audit system has to be
disabled. You would run "auditctl -e 0" to turn off the audit system. OR if you
are using rsyslog, then you can probably write a filter so that it removes
audit events as it finds them.
-Steve
^ permalink raw reply
* Re: Failure flag "0" doesn't work
From: Burn Alting @ 2015-08-20 22:15 UTC (permalink / raw)
To: Alex Beljanski; +Cc: linux-audit
In-Reply-To: <CAJeTBw8mAYC0RTjuVKC84tEfUVKsB+F_JASkJu4rOQVREV9DOw@mail.gmail.com>
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@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@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
>
^ permalink raw reply
* User Login Lifecycle events
From: Steve Grubb @ 2015-08-20 18:16 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply
* Re: Failure flag "0" doesn't work
From: Burn Alting @ 2015-08-20 9:39 UTC (permalink / raw)
To: Alex Beljanski; +Cc: linux-audit
In-Reply-To: <CAJeTBw8Kc-+hJvRpwdjprUWi8PY-dqdSToY_MY=SBNRYY+PCZA@mail.gmail.com>
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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Failure flag "0" doesn't work
From: Alex Beljanski @ 2015-08-20 8:09 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 319 bytes --]
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?
[-- Attachment #1.2: Type: text/html, Size: 471 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: audit 2.4.4 released
From: Steve Grubb @ 2015-08-14 17:04 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <55CE17C0.9000307@magitekltd.com>
On Friday, August 14, 2015 09:30:56 AM LC Bruzenak wrote:
> On 08/13/2015 02:30 PM, Steve Grubb wrote:
> > ...
> >
> > 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.
>
> Wow; that's something unexpected. Thanks for this extra info Steve; I
> may need to backport to my version.
> Are these changes isolated to the ausearch/aureport code sets or inside
> libs?
Well, that's where it gets complicated. Ausearch was converted to use auparse
for interpretations a while back. So, I had to patch the whole mess. Any
utility that uses auparse can also unwittingly pass along terminal escape
sequences through the interpret function.
So, what I did in auparse is to create a new function:
auparse_set_escape_mode. It takes one argument which can be any of:
AUPARSE_ESC_RAW - do nothing. Just passes control characters and all.
AUPARSE_ESC_TTY - escape control characters by turning them to octal. This is
the same thing syslog does. This is the default.
AUPARSE_ESC_SHELL - escape control characters and any of these "'`$\ by
prepending a \ to the character
AUPARSE_ESC_SHELL_QUOTE - escape control characters and any of these ;'"`#$&*?
[]<>{}\ by prepending a \ to the character.
Once this is set, every output from auparse is escaped. This will allow
ausearch/report to shell escape output in a future release. Additionally, it
was found you could inject control characters by the auditctl command. It now
prevents that.
So, the patch is rather large and ugly:
https://fedorahosted.org/audit/changeset/1122
You have to be on a susceptible terminal emulator to have any real problems.
Its for this reason the Security Response Team rates this as low. But in terms
of audit, you don't want a file path to suddenly change to black on black text
so that you can't see the full path.
-Steve
^ permalink raw reply
* Re: audit 2.4.4 released
From: LC Bruzenak @ 2015-08-14 16:30 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1485640.eHOhO3r53z@x2>
On 08/13/2015 02:30 PM, Steve Grubb wrote:
> ...
>
> 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.
>
Wow; that's something unexpected. Thanks for this extra info Steve; I
may need to backport to my version.
Are these changes isolated to the ausearch/aureport code sets or inside
libs?
Thx,
LCB
--
LC Bruzenak
magitekltd.com
^ permalink raw reply
* audit 2.4.4 released
From: Steve Grubb @ 2015-08-13 21:30 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply
* Re: auditing kdbus service names
From: Steve Grubb @ 2015-08-13 20:40 UTC (permalink / raw)
To: Paul Moore; +Cc: Paul Osmialowski, linux-security-module, linux-audit, selinux
In-Reply-To: <1988863.rx1nHfWkfd@sifl>
On Wednesday, August 12, 2015 10:48:10 PM Paul Moore wrote:
> On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> > On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > > 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?
> >
> > What was used on the old dbus events?
>
> The very generic "service" field name, see the "acquire_svc" example in the
> URL below. I believe there is some value in picking a new field name since
> 1) the field name is too generic in my opinion and 2) kdbus != dbus.
In my book, they are the same. They are programs providing services on the
bus. One thing I noticed in the dbus events is that there are a number of user
controlled fields that are not escaped.
Call it kdbus_svc if you want, but log it untrusted.
Thanks,
-Steve
^ permalink raw reply
* Re: auditing kdbus service names
From: Paul Moore @ 2015-08-13 2:48 UTC (permalink / raw)
To: Steve Grubb; +Cc: Paul Osmialowski, linux-security-module, linux-audit, selinux
In-Reply-To: <18456537.MDqL7RWdSn@x2>
On Wednesday, August 12, 2015 05:38:14 PM Steve Grubb wrote:
> On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> > 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?
>
> What was used on the old dbus events?
The very generic "service" field name, see the "acquire_svc" example in the
URL below. I believe there is some value in picking a new field name since 1)
the field name is too generic in my opinion and 2) kdbus != dbus.
* http://lists.freedesktop.org/archives/dbus/2004-November/001728.html
--
paul moore
security @ redhat
^ permalink raw reply
* Re: [PATCH V10] fixup: audit: implement audit by executable
From: Paul Moore @ 2015-08-13 2:30 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: linux-audit, linux-kernel, sgrubb, eparis, peter
In-Reply-To: <20150812151944.GC25337@madcap2.tricolour.ca>
On Wednesday, August 12, 2015 11:19:44 AM Richard Guy Briggs wrote:
> On 15/08/12, Paul Moore wrote:
> > On Wednesday, August 12, 2015 05:48:48 AM Richard Guy Briggs wrote:
> > > Do you plan to push this fix to next?
> >
> > Patience. Yes, I'll be pushing this to next sometime this week; as usual
> > I'll send mail when I do.
>
> Ok, no problem, I'm not rushing. I was unsure what your intentions were
> or whether there was more to do to help it happen.
It's merged. I still don't know why I'm seeing that error, but the patch is
obviously correct so I'm just going to merge it anyway and chalk it up to some
compiler/sparse oddity.
As far as patch follow-ups, if you haven't heard back from me after four days
or so (yes, that is as arbitrary as it sounds), it isn't a bad idea to send a
follow-up, especially if it is a critical patch, to make sure I've seen the
patch (things do occasionally fall through the cracks). However, if it is
only been a day or two and I haven't responded, rest assured I've likely seen
your patch I'm just dealing with something else at the moment and haven't had
the time to review/comment/merge your patch.
--
paul moore
security @ redhat
^ permalink raw reply
* Re: auditing kdbus service names
From: Steve Grubb @ 2015-08-12 21:38 UTC (permalink / raw)
To: linux-audit; +Cc: Paul Osmialowski, linux-security-module, selinux
In-Reply-To: <3754565.WlII3JJvve@sifl>
On Wednesday, August 12, 2015 08:40:34 AM Paul Moore wrote:
> 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?
What was used on the old dbus events?
-Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox