Weird issues in 2.6.5

Wed Jul 13 17:51:07 UTC 2016

The only reason I am even upgrading is because of the issues with
audisp-remote, the not-reconnecting, and the apparent client-side
buffering, that went away with 2.4.x and 2.6.x.  So if we decide to ship
logs a different way than with audisp-remote, then it might be best to
stick with 1.7.x.

That said, so far I see no issues, so we're going to forge ahead and see
what happens.  I just need to keep in mind what our mitigation plan would
be if we do run into issues.

Thanks!

On Wed, Jul 13, 2016 at 10:07 AM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Wednesday, July 13, 2016 9:55:32 AM EDT Chris Nandor wrote:
> > I'll try that module and those rules out, thanks.
> >
> > Also, do you forsee issues with using 2.6.x userspace on ubuntu12.04,
> which
> > is about four years old now?  Its kernel version 3.2.0-99-generic.
>
> That's a tricky question for me to answer. You would probably be in a non-
> supported position. I also don't know if they have made any patches for
> APP_ARMOR support in the audit system. There are a few things that auditctl
> might look for in newer kernels but it should gracefully handle it. It
> should
> be compatible with the rest of user space.
>
> So, give it a try. It may work. It should be easy to go back if something
> is
> wrong.
>
> -Steve
>
> > On Wed, Jul 13, 2016 at 9:32 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > On Wednesday, July 13, 2016 9:22:57 AM EDT Chris Nandor wrote:
> > > > Secondary question: the reason for what I'm working on is that we
> want
> > > > to
> > > > be able to audit what folks do as root on our production hosts.
> We're
> > >
> > > not
> > >
> > > > a bank, and a perfect solution is not required, but we do need to be
> > > > able
> > > > to take reasonable steps to find out if people with access are doing
> bad
> > > > things.
> > > >
> > > > Is this setup reasonable for that purpose?
> > >
> > > Yes. You would want to do two things, first enable tty auditing. This
> is
> > > done
> > > by the pam_tty_audit module. Second consider adding the
> > > 32-power-abuse.rules
> > > to your rules.
> > >
> > > > I know that's a loaded question
> > > > and I can answer any questions anyone has that are necessary to
> figure
> > >
> > > this
> > >
> > > > out.  I am not asking so much about rules, but about architecture:
> > > logging
> > >
> > > > according to whatever rules we set up, to the local audit.log and
> > > > immediately to a remote using audisp-remote, so the log can't be
> easily
> > > > manipulated.
> > >
> > > Remote logging is the defence against local log manipulation.
> > >
> > > -Steve
> > >
> > > > On Wed, Jul 13, 2016 at 8:57 AM, Steve Grubb <sgrubb at redhat.com>
> wrote:
> > > > > On Wednesday, July 13, 2016 8:47:58 AM EDT Chris Nandor wrote:
> > > > > > Hi, I had some odd behavior to report.
> > > > > >
> > > > > > I am running ubuntu 12.04.  Using the default auditd and
> > >
> > > audispd-plugins
> > >
> > > > > > packages for my release, I was able to get logs sent to local
> syslog
> > >
> > > and
> > >
> > > > > to
> > > > >
> > > > > > a remote auditd server (same basic configuration), but the
> entries
> > >
> > > were
> > >
> > > > > > being buffered somewhere (I think on the client side), and if the
> > >
> > > server
> > >
> > > > > > died reconnections didn't happen.
> > > > > >
> > > > > > So, I wanted a more recent version, so I compiled audit-userspace
> > >
> > > from
> > >
> > > > > the
> > > > >
> > > > > > github src mirror,* trunk at 1341.
> > > > >
> > > > > The github repo is a mirror of svn and is not always up to date.
> The
> > >
> > > issue
> > >
> > > > > you
> > > > > are seeing is fixed in the next commit after the mirror stops.
> > > > >
> > > > > https://fedorahosted.org/audit/changeset/1342
> > > > >
> > > > > if you want the lastest you can:
> > > > >
> > > > > svn co http://svn.fedorahosted.org/svn/audit/trunk
> > > > >
> > > > > and then generate from there. I am planning to release audit-2.6.5
> > > > > tomorrow.
> > > > > So, if anyone can test the current code, I'd really appreciate it.
> I'm
> > > > > hoping
> > > > > the next release settles down the audit code.
> > > > >
> > > > > > When I did, I got some weird results.  For example, I expected
> got
> > > > > >
> > > > > > something like this in my audit.log:
> > > > > >   node=host.example.com type=CWD
> msg=audit(1468363871.644:3279856):
> > > > > >  cwd="/etc/audisp"
> > > > > >
> > > > > > And that was as expected.  In syslog, I expected to get:
> > > > > >   Jul 13 08:34:53 host audispd: node=host.loc.example.com
> type=CWD
> > > > > >
> > > > > > msg=audit(1468363871.644:3279856):  cwd="/etc/audisp"
> > > > > >
> > > > > > But instead, I got:
> > > > > >   Jul 13 08:34:53 host audispd: type=CWD msg=node=
> > >
> > > host.loc.example.com
> > >
> > > > > > type=CWD msg=audit(1468363871.644
> > > > > >
> > > > > > As you can see, the whole thing was prepended with "type=CWD
> msg=",
> > >
> > > and
> > >
> > > > > the
> > > > >
> > > > > > line was truncated.  Similarly, on the remote host, I got the
> same
> > >
> > > thing:
> > > > > >   type=CWD msg=node=host.loc.example.com type=CWD
> > > > >
> > > > > msg=audit(1468363871.644
> > > > >
> > > > > > I noticed that the most recent version of the src for ubuntu was
> > >
> > > 2.4.5,
> > >
> > > > > so
> > > > >
> > > > > > I grabbed the src tarball from packages.ubuntu and built it, and
> now
> > > > > > everything looks fine.  The exact same line I see in my audit.log
> > >
> > > shows
> > >
> > > > > up
> > > > >
> > > > > > in the remote audit.log, with no buffering.  When I restart the
> > >
> > > remote
> > >
> > > > > > auditd server or client, it reconnects.  syslog has same entry
> > > > > > (prepended
> > > > > > with the timestamp etc.).  Everything seems happy now.
> > > > > >
> > > > > >
> > > > > > *For some reason I had to define `CC_FOR_BUILD=gcc` in my shell
> when
> > >
> > > I
> > >
> > > > > ran
> > > > >
> > > > > > `make` from the svn/git src.  I did not require this when
> building
> > >
> > > 2.4.5
> > >
> > > > > > from the ubuntu src.
> > > > >
> > > > > I think that should have been detected during configure.
> > > > >
> > > > > -Steve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20160713/48a403a6/attachment.htm>