audit.rules not fully loading into memory according to auditctl -l

Wed Apr 12 19:00:59 UTC 2017

Yes, certainly.

I had a 1.7GB messages file in /var/log; so I moved it manually out of the
way.  Then I rebooted.

After doing that, I didn't see anything at all about auditd in the new
/var/log/messages.

I have finally gotten it down to 13 audit rules, all still Action Rules
only for some reason, that are not loading into memory from
/etc/audit/audit.rules.
Those action rules are using -F path= attributes.

What is really interesting is that I have other action rules using -F path=
that are getting into memory!

These are the files that are not:
/usr/libexec/kde4/kdesud
/usr/libexec/openssh/ssh-keysign
/usr/libexec/polkit-1/polkit-agent-helper-1
/usr/libexec/pt_chown
/usr/libexec/utempter/utempter
/usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper
/usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper
/usr/sbin/lockdev
/usr/sbin/postdrop
/usr/sbin/postqueue
/usr/sbin/suexec
/usr/sbin/userhelper
/usr/sbin/usernetctl

I did the following to evaluate---
for FIL in `cat audit_action_rules_File | grep -v "^#" | awk '{ print $4 }'
| cut -d= -f 2`; do
   echo "Checking for ${FIL}."
   if [ -f ${FIL} ]; then
      echo "${FIL} is present."
   else
      echo "The file ${FIL} is not present."
   fi
done

Checking for /usr/libexec/kde4/kdesud.
*The file /usr/libexec/kde4/kdesud is not present.*
Checking for /usr/libexec/openssh/ssh-keysign.
/usr/libexec/openssh/ssh-keysign is present.
Checking for /usr/libexec/polkit-1/polkit-agent-helper-1.
/usr/libexec/polkit-1/polkit-agent-helper-1 is present.
Checking for /usr/libexec/pt_chown.
/usr/libexec/pt_chown is present.
Checking for /usr/libexec/utempter/utempter.
/usr/libexec/utempter/utempter is present.
Checking for /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper.
*The file /usr/lib/vmware-tools/bin32/vmware-user-suid-wrapper is not
present.*
Checking for /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper.
*The file /usr/lib/vmware-tools/bin64/vmware-user-suid-wrapper is not
present.*
Checking for /usr/sbin/lockdev.
/usr/sbin/lockdev is present.
Checking for /usr/sbin/postdrop.
/usr/sbin/postdrop is present.
Checking for /usr/sbin/postqueue.
/usr/sbin/postqueue is present.
Checking for /usr/sbin/suexec.
/usr/sbin/suexec is present.
Checking for /usr/sbin/userhelper.
/usr/sbin/userhelper is present.
Checking for /usr/sbin/usernetctl.
/usr/sbin/usernetctl is present.

I am still missing all 15 Watch rules in memory.

--------------------------
Warron French

On Wed, Apr 12, 2017 at 2:05 PM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Wednesday, April 12, 2017 1:40:51 PM EDT warron.french wrote:
> > Didn't know to check there.
>
> Shouldn't we keep the discussion on the mail list so others can learn from
> it?
>
> -Steve
>
> > Also, I noticed something interesting after tracing through rules I
> > captured from audit.rules (and sorting) and capturing rules from auditctl
> > (also sorting).
> >
> > Here are some things I observed:
> >
> >    1.  -a  -F path= <path/to/file> are not getting loaded at all.
> >    2. -a -S call1 -S call2 -S call3 -S callN are being altered into a
> >    relative format  of   -a -S call1,call2,call3,callN       (I was not
> >    expecting this at all).
> >
> > I will look at the syslog output from auditctl in /var/log/messages
> > (correct?).
> >
> >
> >
> > --------------------------
> > Warron French
> >
> > On Wed, Apr 12, 2017 at 1:22 PM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > On Wednesday, April 12, 2017 12:51:03 PM EDT warron.french wrote:
> > > > Hello, I am writing a Puppet Module to deliver updates of audit.rules
> > > > and
> > > > auditd.conf configurations to RHEL6 and RHEL7 machines.
> > > >
> > > > The files are laid down correctly for both RHEL6 and RHEL7 within the
> > > >
> > > > appropriate directories:
> > > >    - RHEL6 = /etc/audit/audit.rules, for
> > > >    - RHEL7 = /etc/audit/rules.d/audit.rules
> > > >
> > > > Anyway, the results for all RHEL7 machines (client versus Server) are
> > > > perfect.  The audit.rules are all laid down as expected, and after a
> > >
> > > reboot
> > >
> > > > of the system the rules are all 100% in place - just as I need.
> > > >
> > > > The problem is when they are laid down on RHEL6 clients versus
> Servers,
> > >
> > > the
> > >
> > > > behaviors are very different.
> > > >
> > > > For RHEL6 clients I have the following intentions and loaded into
> > > > memory:
> > > >
> > > > 118 (-a) Action Rules in audit.rules file        118 Action Rules are
> > > > loaded into memory (YAY!)
> > > >
> > > > * 15 (-w) Watch Rules* in audit.rules file       *  15 Watch Rules
> are
> > > > loaded into memory* (YAY!)
> > > >
> > > > 133 Total Rules in audit.rules files              133 Total Rules
> into
> > > > memory (YAY!)
> > > >
> > > >
> > > > For RHEL6 Server; however, I have the following results:
> > > >
> > > > 118 (-a) Action Rules in audit.rules file    105 Action Rules are
> loaded
> > > > into memory (FAIL)
> > > >
> > > > * 15 (-w) Watch Rules* in audit.rules file    *   0  Watch Rules are
> > >
> > > loaded
> > >
> > > > into memory* (HUGE FAIL)
> > > >
> > > > 133 Total Rules in audit.rules files           105 Total Rules into
> > >
> > > memory
> > >
> > > > (YAY!)
> > > >
> > > >
> > > > This is really a big problem for me.  Can someone help?
> > >
> > > Was there anything in syslog from auditctl?
> > >
> > > When auditctl runs across a rule with syntax errors, the default
> action is
> > > to
> > > log it and stop. This way it causes the most noticeable thing to
> happen.
> > > However, some people don't like this behavior so they pass a '-c'
> option
> > > near
> > > the beginning of the rules. This causes it to keep processing but
> > > ultimately
> > > return an error at exit. Some people didn't like that auditctl
> returned an
> > > error, so the '-i' option was created for people that can't be bothered
> > > with
> > > failure even in the face of failure.
> > >
> > > Check for a syntax error in the rules. It should be in syslog.
> > >
> > > -Steve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20170412/5c14d7b6/attachment.htm>