Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
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 12:32:55 -0400	[thread overview]
Message-ID: <1592387.yc9HYPXd4B@x2> (raw)
In-Reply-To: <CAHcE2wryUe3E0LtMn2WijR9w_Wu0Mg2+TWeQbq2aUUPEKiTX-A@mail.gmail.com>

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

  reply	other threads:[~2016-07-13 16:32 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 [this message]
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
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=1592387.yc9HYPXd4B@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