From: Steve Grubb <sgrubb@redhat.com>
To: Chris Nandor <pudge@pobox.com>
Cc: linux-audit@redhat.com
Subject: Re: Weird issues in 2.6.5
Date: Wed, 13 Jul 2016 13:07:42 -0400 [thread overview]
Message-ID: <2784296.CQpCvJAsZs@x2> (raw)
In-Reply-To: <CAHcE2wpg3A4x-D1dG-PKwNTpnRnWH0=3crPp+PFccXkNyPg_wA@mail.gmail.com>
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@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@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@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 prev parent reply other threads:[~2016-07-13 17:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 15:47 Weird issues in 2.6.5 Chris Nandor
2016-07-13 15:57 ` Steve Grubb
2016-07-13 16:22 ` Chris Nandor
2016-07-13 16:32 ` Steve Grubb
2016-07-13 16:42 ` Steve Grubb
2016-07-13 16:51 ` Chris Nandor
2016-07-13 16:55 ` Chris Nandor
2016-07-13 17:07 ` Steve Grubb [this message]
2016-07-13 17:51 ` Chris Nandor
2016-07-13 18:38 ` Steve Grubb
2016-07-13 18:45 ` Chris Nandor
2016-07-13 22:22 ` Chris Nandor
2016-07-15 1:09 ` Steve Grubb
2016-07-13 21:14 ` Chris Nandor
2016-07-13 21:11 ` Chris Nandor
2016-07-13 16:20 ` Richard Guy Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2784296.CQpCvJAsZs@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=pudge@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox