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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.