* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 21:11 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <17910807.r7x1d9MGge@x2>
[-- Attachment #1.1: Type: text/plain, Size: 2790 bytes --]
I've been using the latest (@r1347) for the last couple of hours, and the
problems I saw have gone away.
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
>
[-- Attachment #1.2: Type: text/html, Size: 4027 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 18:45 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <3857340.Akeo5bVtPE@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1338 bytes --]
Since we're new to auditd, there's no old utilities so far that we're
using, so I don't see a problem there. I think.
On Wed, Jul 13, 2016 at 11:38 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 10:51:07 AM EDT Chris Nandor wrote:
> > 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.
>
> This sounds a lot like the idle detection is not set right. In audisp-
> remote.conf there is a setting heartbeat_timeout. This should be set to
> something like 60 or 120. Then on the server in auditd.conf there is a
> setting
> tcp_client_max_idle which should be over twice as high as
> heartbeat_timeout.
> So, you'd set it to 180 or 300.
>
> > 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.
>
> Old utilities won't know what to do with enriched events. AFAICS, that
> would
> be the long term issue. You'll need to do aperl, awk, or cut command to
> trim
> off the unknown part of the event in your logs.
>
> -Steve
>
[-- Attachment #1.2: Type: text/html, Size: 1850 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-13 18:38 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
In-Reply-To: <CAHcE2woRZK_Rt9oDomHGjGD2Y8uBm58s5ge9c7qFOW+eoM_2sA@mail.gmail.com>
On Wednesday, July 13, 2016 10:51:07 AM EDT Chris Nandor wrote:
> 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.
This sounds a lot like the idle detection is not set right. In audisp-
remote.conf there is a setting heartbeat_timeout. This should be set to
something like 60 or 120. Then on the server in auditd.conf there is a setting
tcp_client_max_idle which should be over twice as high as heartbeat_timeout.
So, you'd set it to 180 or 300.
> 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.
Old utilities won't know what to do with enriched events. AFAICS, that would
be the long term issue. You'll need to do aperl, awk, or cut command to trim
off the unknown part of the event in your logs.
-Steve
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 17:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <2784296.CQpCvJAsZs@x2>
[-- Attachment #1.1: Type: text/plain, Size: 6201 bytes --]
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@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@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
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 9354 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-13 17:07 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
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
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 16:55 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <1592387.yc9HYPXd4B@x2>
[-- Attachment #1.1: Type: text/plain, Size: 4413 bytes --]
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.
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
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 6461 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 16:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <4163033.HK5e6qXJ5d@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1628 bytes --]
Yeah, I saw that (and tried it out, but reverted when I noticed the
truncation issues). Nice feature!
On Wed, Jul 13, 2016 at 9:42 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 12:32:55 PM EDT Steve Grubb 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.
>
> Another thing to consider is that the 2.6 version of the audit user space
> has
> a new logging format. You might consider going into auditd.conf and setting
> log_format = enriched. This resolves some information locally before
> sending
> it to the remote system.
>
> -Steve
>
[-- Attachment #1.2: Type: text/html, Size: 2203 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: euid missing
From: Chris Nandor @ 2016-07-13 16:51 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <4373501.sMjiJxmkID@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1577 bytes --]
Ah, thanks. I had only recently added -k rootcmd so I didn't notice it was
different earlier ... but I should've noticed this time. Thanks!
On Wed, Jul 13, 2016 at 9:39 AM, Steve Grubb <sgrubb@redhat.com> wrote:
> On Wednesday, July 13, 2016 9:27:25 AM EDT Chris Nandor wrote:
> > As mentioned in previous e-mail, we want to log what users do as root. I
> > have these two rules, only:
> >
> > -a exit,always -F arch=b32 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
> > execve -k rootcmd
> > -a exit,always -F arch=b64 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
> > execve -k rootcmd
> >
> > But this line shows up:
> >
> > node=grax.sea.marchex.com type=ANOM_ABEND
> > msg=audit(1468426871.752:3282575): auid=811 uid=811 gid=811 ses=12
> > pid=18504 comm="chromium-browse" reason="seccomp" sig=0 syscall=91
> compat=0
> > ip=0x7f296c759c77 code=0x50001
>
> There are two kinds of events. There are the ones that are triggered by the
> rules you load, and there are rules that are hardwired to be logged because
> something significant happened. In this case the seccomp filter killed
> chromium-browse because it violated policy. It has nothing to do with your
> rules which have a rootcmd key.
>
> To find the events triggered by your rule, use:
> ausearch --start today -k rootcmd -i
>
> -Steve
>
> > My guess is that it is because euid is missing; maybe euid=0 is true if
> > euid is null? I could put uid=0, instead of euid ... but that isn't
> > exactly what I want, I think. Is there a way to have the rule require
> euid
> > actually be 0?
> >
> > --Chris
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 2279 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-13 16:42 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <1592387.yc9HYPXd4B@x2>
On Wednesday, July 13, 2016 12:32:55 PM EDT Steve Grubb 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.
Another thing to consider is that the 2.6 version of the audit user space has
a new logging format. You might consider going into auditd.conf and setting
log_format = enriched. This resolves some information locally before sending
it to the remote system.
-Steve
^ permalink raw reply
* Re: euid missing
From: Steve Grubb @ 2016-07-13 16:39 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHcE2wp8nCcqfeUMLd6pHuqWfKYbGFm67+w6S1DipoiO0Bf0pA@mail.gmail.com>
On Wednesday, July 13, 2016 9:27:25 AM EDT Chris Nandor wrote:
> As mentioned in previous e-mail, we want to log what users do as root. I
> have these two rules, only:
>
> -a exit,always -F arch=b32 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
> execve -k rootcmd
> -a exit,always -F arch=b64 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
> execve -k rootcmd
>
> But this line shows up:
>
> node=grax.sea.marchex.com type=ANOM_ABEND
> msg=audit(1468426871.752:3282575): auid=811 uid=811 gid=811 ses=12
> pid=18504 comm="chromium-browse" reason="seccomp" sig=0 syscall=91 compat=0
> ip=0x7f296c759c77 code=0x50001
There are two kinds of events. There are the ones that are triggered by the
rules you load, and there are rules that are hardwired to be logged because
something significant happened. In this case the seccomp filter killed
chromium-browse because it violated policy. It has nothing to do with your
rules which have a rootcmd key.
To find the events triggered by your rule, use:
ausearch --start today -k rootcmd -i
-Steve
> My guess is that it is because euid is missing; maybe euid=0 is true if
> euid is null? I could put uid=0, instead of euid ... but that isn't
> exactly what I want, I think. Is there a way to have the rule require euid
> actually be 0?
>
> --Chris
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-13 16:32 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
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
^ permalink raw reply
* euid missing
From: Chris Nandor @ 2016-07-13 16:27 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 765 bytes --]
As mentioned in previous e-mail, we want to log what users do as root. I
have these two rules, only:
-a exit,always -F arch=b32 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
execve -k rootcmd
-a exit,always -F arch=b64 -F euid=0 -F auid>=0 -F auid!=4294967295 -S
execve -k rootcmd
But this line shows up:
node=grax.sea.marchex.com type=ANOM_ABEND
msg=audit(1468426871.752:3282575): auid=811 uid=811 gid=811 ses=12
pid=18504 comm="chromium-browse" reason="seccomp" sig=0 syscall=91 compat=0
ip=0x7f296c759c77 code=0x50001
My guess is that it is because euid is missing; maybe euid=0 is true if
euid is null? I could put uid=0, instead of euid ... but that isn't
exactly what I want, I think. Is there a way to have the rule require euid
actually be 0?
--Chris
[-- Attachment #1.2: Type: text/html, Size: 1040 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 16:22 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit
In-Reply-To: <17910807.r7x1d9MGge@x2>
[-- Attachment #1.1: Type: text/plain, Size: 3429 bytes --]
Thanks, I'll try building with the actual latest in a bit.
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? 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.
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
>
[-- Attachment #1.2: Type: text/html, Size: 4755 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Richard Guy Briggs @ 2016-07-13 16:20 UTC (permalink / raw)
To: Chris Nandor; +Cc: linux-audit
In-Reply-To: <CAHcE2wqW0c16dBbEuAJDBM0MZrow0eHLf6JdW_485gGvkbrQQg@mail.gmail.com>
On 2016-07-13 08:47, Chris Nandor wrote:
> *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.
Ok, so it isn't just me. I had a similar problem a couple of months ago
when building from current source on RHEL6.
> --Chris
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: Weird issues in 2.6.5
From: Steve Grubb @ 2016-07-13 15:57 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <CAHcE2wqW0c16dBbEuAJDBM0MZrow0eHLf6JdW_485gGvkbrQQg@mail.gmail.com>
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
^ permalink raw reply
* Weird issues in 2.6.5
From: Chris Nandor @ 2016-07-13 15:47 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 1804 bytes --]
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.
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.
--Chris
[-- Attachment #1.2: Type: text/html, Size: 2449 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Questions about the standard (Google Summer of Code Project)
From: Steve Grubb @ 2016-07-13 14:23 UTC (permalink / raw)
To: linux-audit; +Cc: Konrad Witaszczyk
In-Reply-To: <B946B6D5-FA5C-436A-AF7E-A5B50E3FAAE6@FreeBSD.org>
Hello,
On Wednesday, July 13, 2016 1:23:29 PM EDT Mateusz Piotrowski wrote:
> I participate in Google Summer of Code and my project involves converting
> Linux Audit logs to BSM logs.
>
> As I was writing a parser and converter I stumbled upon a couple of things I
> do not understand and I cannot find in the documentation:
The linux audit system has a library, libauparse, that encapsulates all the
quirks of the audit system so that writing applications like a translator is
easy. I would recommend using that as a starting point so that you don't have
to recreate it from scratch.
> 1. Where are all the elements like auditd start, user, etc. listed? I cannot
> find any document which specifies what can occurs between the colon
> (separating the type and the msg=audit(…) from the fields) and the record’s
> fields.
There really is none, Libauparse takes care of all of this so that you don't
have to. If you are wanting to do translation, you can feed the logs into
auparse and then just format the event the way you want.
That said, there is a big change coming soon which might make your project
easier. I'm planning to create a field classification extension to auparse that
will allow you to say, "give me the subject of this event", "give me the
action being performed", "give me the object", "give me the results". This
would probably make tranlators of all kinds easier to write.
> 2. Why are there two spaces between the colon and the first field in records
> of type=CWD and a field cwd=“/root”? Here’s an example:
>
> type=CWD msg=audit(1464013682.961:409): cwd="/root”
Human error? We use strtok_r to parse and it doesn't care.
> 3. According to Red Hat’s documentation[1]:
> > Each record consists of several name=value pairs separated by a white
> > space or a comma.
> a) Is a white space always a space?
Yes.
> Can be any white space like the tab character?
No.
> b) Why do some records are separated by a comma and a
> whitespace? Example:
>
> type=DAEMON_START msg=audit(1363713609.192:5426): auditd start,
> ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979
> subj=unconfined_u:system_r:auditd_t:s0 res=success
A long time ago the records were meant to be both human readable (don't laugh)
and machine consumable. Over time these have been converted name=value pairs.
Even the one you mention above has been fixed.
> I’ve posted the question on Unix & Linux SE: [3].
>
> 4. Is it possible that there are duplicate fields in a record?
Sometimes. I've tried to fix those when it happens. The problem is that not
everyone runs their audit code by this mail list so that we can check it to
see that its well formed. What I am planning to do is write an audit event
validation suite that checks that events are well formed and that expected
events are being written when they are supposed to and in the order that they
are supoosed to. Cleaning up these events is high on my TODO list.
> Something
> like (which doesn’t make much sense obviously):
>
> type=CWD msg=audit(1464013682.961:409): cwd="/root” cwd=“/usr”
Something like this will not happen, its more likely around auid and uid. The
reason being that the kernel adds somethings automatically because its a
trusted source of information. User space can write contradictory information.
For example if a daemon is working on behalf of a user but its auid has not
been set for the user, then you might see this.
> I’ve already asked a similar question on Unix & Linux SE: [4].
This mail list is where you will get the best answers.
> 5. Is there a document which answers my questions? That would be cool!
https://github.com/linux-audit/audit-documentation/wiki
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Upgrading audit package
From: Steve Grubb @ 2016-07-13 12:59 UTC (permalink / raw)
To: Bhagwat, Shriniketan Manjunath; +Cc: linux-audit@redhat.com
In-Reply-To: <AT5PR84MB014747BF10579EC4098CC733FA310@AT5PR84MB0147.NAMPRD84.PROD.OUTLOOK.COM>
Hello,
On Wednesday, July 13, 2016 5:38:38 AM EDT Bhagwat, Shriniketan Manjunath
wrote:
> As requested in my previous email, I am interested in understanding the
> relation between Linux audit kernel and user space audit. Will a audit
> kernel available with Linux kernel 2.6.32 compatible with user space audit
> 2.6.X? I understand you might be busy with your regular schedules. :-)
To some extent, yes they are compatible. How much? I don't know. I have never
tried that combination because they were never meant to run together.
-Steve
> From: Bhagwat, Shriniketan Manjunath
> Sent: Monday, July 11, 2016 1:48 PM
> To: 'Steve Grubb' <sgrubb@redhat.com>
> Cc: linux-audit@redhat.com
> Subject: Upgrading audit package
>
> Hi Steve,
>
> I am using audit in my development environment. My development environment
> is as below.
>
> RHEL 5.2 with kernel 2.6.32-431.el6.x86_64 and audit-2.2-2.el6.x86_64.
> SUSE 11 SP3 with kernel 3.0.76-0.11-default and audit-1.8-0.30.1
>
> As I understand the above audit packages I am using in my environment are
> user space audit. I want to upgrade it to the latest version. If I upgrade
> the audit packages to latest version 2.6.X will there be any issues? Linux
> Audit kernel available with kernel 2.6.32-431.el6.x86_64 and 3.0.76-0.11
> are compatible with user space audit 2.6.X? In your opinion what is the
> suitable audit package for my environment to upgrade? If these topics are
> already documented please guide me to the documentation.
>
> Regards,
> Ketan
^ permalink raw reply
* Questions about the standard (Google Summer of Code Project)
From: Mateusz Piotrowski @ 2016-07-13 11:23 UTC (permalink / raw)
To: linux-audit; +Cc: Konrad Witaszczyk
[-- Attachment #1.1: Type: text/plain, Size: 2549 bytes --]
Hi,
I participate in Google Summer of Code and my project involves converting Linux Audit logs to BSM logs.
As I was writing a parser and converter I stumbled upon a couple of things I do not understand and I cannot find in the documentation:
1. Where are all the elements like auditd start, user, etc. listed? I cannot find any document which specifies what can occurs between the colon (separating the type and the msg=audit(…) from the fields) and the record’s fields.
2. Why are there two spaces between the colon and the first field in records of type=CWD and a field cwd=“/root”? Here’s an example:
type=CWD msg=audit(1464013682.961:409): cwd="/root”
3. According to Red Hat’s documentation[1]:
> Each record consists of several name=value pairs separated by a white space or a comma.
a) Is a white space always a space? Can be any white space like the tab character?
b) Why do some records are separated by a comma and a whitespace? Example:
type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success
I’ve posted the question on Unix & Linux SE: [3].
4. Is it possible that there are duplicate fields in a record? Something like (which doesn’t make much sense obviously):
type=CWD msg=audit(1464013682.961:409): cwd="/root” cwd=“/usr”
I’ve already asked a similar question on Unix & Linux SE: [4].
5. Is there a document which answers my questions? That would be cool!
Thanks a lot for help!
Cheers!
Matuesz Piotrowski
[GSoC project’s wiki]: https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools <https://wiki.freebsd.org/SummerOfCode2016/NonBSMtoBSMConversionTools>
[1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Understanding_Audit_Log_Files.html <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Understanding_Audit_Log_Files.html>
[3]: http://unix.stackexchange.com/questions/293975/undocumented-format-of-linux-audit-log-records <http://unix.stackexchange.com/questions/293975/undocumented-format-of-linux-audit-log-records>
[4]: http://unix.stackexchange.com/questions/293809/can-i-be-sure-that-the-name-of-a-linux-audit-records-field-is-unique <http://unix.stackexchange.com/questions/293809/can-i-be-sure-that-the-name-of-a-linux-audit-records-field-is-unique>
[-- Attachment #1.2: Type: text/html, Size: 4074 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] capabilities: audit capability use
From: Topi Miettinen @ 2016-07-13 7:30 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, pmladek-IBi9RG/b67k,
luto-DgEjT+Ai2ygdnm+yROfE0A, serge-A9i7LUbDfNHQT0dZR+AlfA,
keescook-F7+t8E8rja9g9hUCZPvPmw, Paul Moore, Eric Paris,
Tejun Heo, Li Zefan, Johannes Weiner,
moderated list:AUDIT SUBSYSTEM, open list:CONTROL GROUP (CGROUP),
open list:CAPABILITIES
In-Reply-To: <878tx79et8.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On 07/12/16 13:16, Eric W. Biederman wrote:
> Topi Miettinen <toiwoton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> On 07/11/16 21:57, Eric W. Biederman wrote:
>>> Topi Miettinen <toiwoton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find
>>>> out useful values for the limits, except blind trial and error.
>>>>
>>>> Currently, there is no way to know which capabilities are actually used.
>>>> Even the source code is only implicit, in-depth knowledge of each
>>>> capability must be used when analyzing a program to judge which
>>>> capabilities the program will exercise.
>>>>
>>>> Generate an audit message at system call exit, when capabilities are used.
>>>> This can then be used to configure capability sets for services by a
>>>> software developer, maintainer or system administrator.
>>>>
>>>> Test case demonstrating basic capability monitoring with the new
>>>> message types 1330 and 1331 and how the cgroups are displayed (boot to
>>>> rdshell):
>>>
>>> You totally miss the interactions with the user namespace so this won't
>>> give you the information you are aiming for.
>>
>> Please correct me if this is not right:
>>
>> There are two cases:
>> a) real capability use as seen outside the namespace
>> b) use of capabilities granted by the namespace
>> Both cases could be active independently.
>>
>> For auditing purposes, we're mostly interested in a) and log noise from
>> b) could be even seen a distraction.
>>
>> For configuration purposes, both cases can be interesting, a) for the
>> configuration of services and b) in case where the containerized
>> configuration is planned to be deployed outside. I'd still only log
>> a).
>>
>>
>> The same logic should apply with cgroup namespaces.
>
> Not logging capabilities outside of the initial user namespace is
> certainly the conservative place to start, and what selinux does.
>
> You should also be logging capability use from cap_capable. Not
But cap_capable is not called from apparmor aa_capable or selinux
selinux_capable, how about security_capable()?
> ns_capable. You are missing several kinds of capability use as
> a quick review of kernel/capability.c should have shown you.
Right, sorry about that.
-Topi
>
> Eric
>
^ permalink raw reply
* Re: [PATCH] capabilities: audit capability use
From: Topi Miettinen @ 2016-07-13 6:52 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, pmladek-IBi9RG/b67k,
luto-DgEjT+Ai2ygdnm+yROfE0A, serge-A9i7LUbDfNHQT0dZR+AlfA,
keescook-F7+t8E8rja9g9hUCZPvPmw, Paul Moore, Eric Paris, Li Zefan,
Johannes Weiner, moderated list:AUDIT SUBSYSTEM,
open list:CONTROL GROUP (CGROUP), open list:CAPABILITIES
In-Reply-To: <20160712145936.GH3190-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
On 07/12/16 14:59, Tejun Heo wrote:
> On Mon, Jul 11, 2016 at 07:47:44PM +0000, Topi Miettinen wrote:
>> It's really critical to be able to associate a task in the logs to
>> cgroups which were valid that time. Or can we infer somehow what cgroups
>
> When is "that time"? Without logging all operations, this is
> meaningless.
>
>> a task was taking part, long time after task exit? Perhaps task cgroup
>> membership changes and changes in available cgroups should be logged too?
>>
>> Some kind of cgroup IDs could be logged instead of long paths. Then
>> these IDs should be reliably resolvable to paths offline somehow.
>
> I don't think that's doable. That pretty much requires the kernel to
> remember paths of all past cgroups.
That's a show stopper for audit approach for getting helpful information
for configuration. I'll try something different, probably cgroupstats.
-Topi
>
>> How usual migrations between cgroups are? Why would a task ever move
>> from (say) systemd/system.slice/smartd.service to anywhere else?
>
> In most cases, they won't move once set up initially but that's not
> the point of audit subsystem. Logging this once one exit isn't gonna
> help anything for auditing the system.
>
> Thanks.
>
^ permalink raw reply
* RE: Upgrading audit package
From: Bhagwat, Shriniketan Manjunath @ 2016-07-13 5:38 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1273 bytes --]
Hi Steve,
As requested in my previous email, I am interested in understanding the relation between Linux audit kernel and user space audit. Will a audit kernel available with Linux kernel 2.6.32 compatible with user space audit 2.6.X?
I understand you might be busy with your regular schedules. :-)
Regards,
Ketan
From: Bhagwat, Shriniketan Manjunath
Sent: Monday, July 11, 2016 1:48 PM
To: 'Steve Grubb' <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Upgrading audit package
Hi Steve,
I am using audit in my development environment. My development environment is as below.
RHEL 5.2 with kernel 2.6.32-431.el6.x86_64 and audit-2.2-2.el6.x86_64.
SUSE 11 SP3 with kernel 3.0.76-0.11-default and audit-1.8-0.30.1
As I understand the above audit packages I am using in my environment are user space audit. I want to upgrade it to the latest version.
If I upgrade the audit packages to latest version 2.6.X will there be any issues?
Linux Audit kernel available with kernel 2.6.32-431.el6.x86_64 and 3.0.76-0.11 are compatible with user space audit 2.6.X?
In your opinion what is the suitable audit package for my environment to upgrade?
If these topics are already documented please guide me to the documentation.
Regards,
Ketan
[-- Attachment #1.2: Type: text/html, Size: 4119 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] capabilities: audit capability use
From: Paul Moore @ 2016-07-12 22:00 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Topi Miettinen, linux-kernel, pmladek, luto, serge, keescook,
Eric Paris, Tejun Heo, Li Zefan, Johannes Weiner,
moderated list:AUDIT SUBSYSTEM, open list:CONTROL GROUP (CGROUP),
open list:CAPABILITIES
In-Reply-To: <878tx79et8.fsf@x220.int.ebiederm.org>
On Tue, Jul 12, 2016 at 9:16 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Not logging capabilities outside of the initial user namespace is
> certainly the conservative place to start, and what selinux does.
FYI, we added some basic userns capability smarts to SELinux in Linux 4.7.
commit 8e4ff6f228e4722cac74db716e308d1da33d744f
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date: Fri Apr 8 13:52:00 2016 -0400
selinux: distinguish non-init user namespace capability checks
Distinguish capability checks against a target associated
with the init user namespace versus capability checks against
a target associated with a non-init user namespace by defining
and using separate security classes for the latter.
This is needed to support e.g. Chrome usage of user namespaces
for the Chrome sandbox without needing to allow Chrome to also
exercise capabilities on targets in the init user namespace.
Suggested-by: Dan Walsh <dwalsh@redhat.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] capabilities: audit capability use
From: Paul Moore @ 2016-07-12 21:56 UTC (permalink / raw)
To: Topi Miettinen, moderated list:AUDIT SUBSYSTEM
Cc: linux-kernel, ebiederm, mladek, luto, serge, keescook, Eric Paris,
Tejun Heo, Li Zefan, Johannes Weiner, Serge Hallyn,
open list:CONTROL GROUP (CGROUP), open list:CAPABILITIES
In-Reply-To: <1468235672-3745-1-git-send-email-toiwoton@gmail.com>
On Mon, Jul 11, 2016 at 7:14 AM, Topi Miettinen <toiwoton@gmail.com> wrote:
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find
> out useful values for the limits, except blind trial and error.
>
> Currently, there is no way to know which capabilities are actually used.
> Even the source code is only implicit, in-depth knowledge of each
> capability must be used when analyzing a program to judge which
> capabilities the program will exercise.
>
> Generate an audit message at system call exit, when capabilities are used.
> This can then be used to configure capability sets for services by a
> software developer, maintainer or system administrator.
>
> Test case demonstrating basic capability monitoring with the new
> message types 1330 and 1331 and how the cgroups are displayed (boot to
> rdshell):
NOTE: additional comments inline with the patch.
I can understand the desire to audit the capabilities, but I'm a
little uncertain about the value of auditing cgroups at this point in
time. The audit subsystem focuses primarily on security relevant
information, and while you could make an argument for cgroups here, I
think it is a relatively weak argument at the moment.
Also, please continue to work on reducing the impact of this on the
audit logs (your discussion with Serge).
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index e38e3fc..971cb2e 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -438,6 +438,8 @@ static inline void audit_mmap_fd(int fd, int flags)
> __audit_mmap_fd(fd, flags);
> }
>
> +extern void audit_log_cap_use(int cap);
> +
> extern int audit_n_rules;
> extern int audit_signals;
> #else /* CONFIG_AUDITSYSCALL */
> @@ -545,6 +547,8 @@ static inline void audit_mmap_fd(int fd, int flags)
> { }
> static inline void audit_ptrace(struct task_struct *t)
> { }
> +static inline void audit_log_cap_use(int cap)
> +{ }
> #define audit_n_rules 0
> #define audit_signals 0
> #endif /* CONFIG_AUDITSYSCALL */
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index a20320c..b5dc8aa 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -100,6 +100,8 @@ char *task_cgroup_path(struct task_struct *task, char *buf, size_t buflen);
> int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry);
> int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
> struct pid *pid, struct task_struct *tsk);
> +struct audit_buffer;
> +void audit_cgroup_list(struct audit_buffer *ab);
>
> void cgroup_fork(struct task_struct *p);
> extern int cgroup_can_fork(struct task_struct *p);
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index d820aa9..c1ae016 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -111,6 +111,8 @@
> #define AUDIT_PROCTITLE 1327 /* Proctitle emit event */
> #define AUDIT_FEATURE_CHANGE 1328 /* audit log listing feature changes */
> #define AUDIT_REPLACE 1329 /* Replace auditd if this packet unanswerd */
> +#define AUDIT_CAPABILITY 1330 /* Record showing capability use */
> +#define AUDIT_CGROUP 1331 /* Record showing cgroups */
As Tejun Heo already stated, please put the capability changes and the
cgroup changes into two separate patches in one patchset.
> #define AUDIT_AVC 1400 /* SE Linux avc denial or grant */
> #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 8d528f9..98dd920 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -54,6 +54,7 @@
> #include <linux/kthread.h>
> #include <linux/kernel.h>
> #include <linux/syscalls.h>
> +#include <linux/cgroup.h>
>
> #include <linux/audit.h>
>
> @@ -1682,7 +1683,7 @@ void audit_log_cap(struct audit_buffer *ab, char *prefix, kernel_cap_t *cap)
> {
> int i;
>
> - audit_log_format(ab, " %s=", prefix);
> + audit_log_format(ab, "%s=", prefix);
Why?
> CAP_FOR_EACH_U32(i) {
> audit_log_format(ab, "%08x",
> cap->cap[CAP_LAST_U32 - i]);
> @@ -1696,11 +1697,11 @@ static void audit_log_fcaps(struct audit_buffer *ab, struct audit_names *name)
> int log = 0;
>
> if (!cap_isclear(*perm)) {
> - audit_log_cap(ab, "cap_fp", perm);
> + audit_log_cap(ab, " cap_fp", perm);
This is not an improvement, please stick with the leading space in
audit_log_cap() so callers do not have to worry about formatting
issues like this.
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 2672d10..32c3813 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1439,6 +1439,18 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts
>
> audit_log_proctitle(tsk, context);
>
> + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CAPABILITY);
> + if (ab) {
> + audit_log_cap(ab, "cap_used", &context->cap_used);
> + audit_log_end(ab);
> + }
> + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CGROUP);
> + if (ab) {
> + audit_log_format(ab, "cgroups=");
> + audit_cgroup_list(ab);
Why not just move the "cgroups=" into audit_cgroup_list()? Can you
ever think of a reason why you would need to record the cgroups
without the "cgroup=" field prefix?
> + audit_log_end(ab);
> + }
> +
> /* Send end of event record to help user space know we are finished */
> ab = audit_log_start(context, GFP_KERNEL, AUDIT_EOE);
> if (ab)
> @@ -2428,3 +2440,17 @@ struct list_head *audit_killed_trees(void)
> return NULL;
> return &ctx->killed_trees;
> }
> +
> +void audit_log_cap_use(int cap)
> +{
> + struct audit_context *context = current->audit_context;
> +
> + if (context) {
> + cap_raise(context->cap_used, cap);
> + audit_set_auditable(context);
> + } else {
> + audit_log(NULL, GFP_NOFS, AUDIT_CAPABILITY,
> + "cap_used=%d pid=%d no audit_context",
> + cap, task_pid_nr(current));
> + }
> +}
You can't log "no audit_context" in the audit record, all information
logged should follow the "<field>=<value>" format.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Trivial patches
From: Steve Grubb @ 2016-07-12 16:31 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <d9f987bb-ba5f-3626-0b5f-4787412124be@debian.org>
Hello,
On Tuesday, July 12, 2016 5:15:01 PM EDT Laurent Bigonville wrote:
> Could you please merge the following patches that have been proposed to
> debian by Nicolas Braud-Santoni?
Yes, thanks.
> The patches add the Documentation key in the .service file and also fix
> some typos.
They are now applied. If anyone has any other bug fixes, please send them.
There will be a 2.6.5 release later this week that fixes events in the old
format that get passed to plugins such as selinux troubleshooter. This is
commit 1342 in case anyone needs it today.
-Steve
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox