All of lore.kernel.org
 help / color / mirror / Atom feed
* Default logging with no rules
@ 2020-11-19 14:04 Andreas Hasenack
  2020-11-19 14:34 ` Steve Grubb
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Hasenack @ 2020-11-19 14:04 UTC (permalink / raw)
  To: Linux-audit

Hi there,

I started playing with the audit subsystem a few days ago, and noticed
that even without any rules, there is a lot of logging going on. I
understand that rules have to be fine tuned, and I was expecting
having to do that, but I wasn't expecting the amount of logs on a busy
system with no rules at all.

I read in an old presentation (~2011) that these come from "trusted
apps", and in fact any process with cap_audit_write (iirc) can log
such events. The tip was that exclude/never list/action could be used
to reduce this noise, is that still the case and recommended approach?
Or is there a way to use audit with only the rules defined in
/etc/audit/rules.d?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Default logging with no rules
  2020-11-19 14:04 Default logging with no rules Andreas Hasenack
@ 2020-11-19 14:34 ` Steve Grubb
  2020-11-19 14:59   ` Andreas Hasenack
  0 siblings, 1 reply; 3+ messages in thread
From: Steve Grubb @ 2020-11-19 14:34 UTC (permalink / raw)
  To: Linux-audit, Andreas Hasenack

On Thursday, November 19, 2020 9:04:24 AM EST Andreas Hasenack wrote:
> I read in an old presentation (~2011) that these come from "trusted
> apps",

There are only 10 - 15 apps that are "trusted apps". They are logging events 
that are required by various security standards such as common criteria, DISA 
STIG, PCI DSS, etc.

> and in fact any process with cap_audit_write (iirc) can log
> such events. 

While that may be true, it is generally not the case that they do in fact 
log.

> The tip was that exclude/never list/action could be used to reduce this
> noise, is that still the case and recommended approach?

If you must, sure. Trusted app events are in the 1100-1199 range. But which 
app is causing the problems that you see? In the past, we had to silence 
crond because it was noisy.

> Or is there a way to use audit with only the rules defined in /etc/audit/
> rules.d?

The rules in that dir are insufficient to fulfill regulatory requirements. If 
you are doing some kind of syscall experiment, then I can see that you might 
want to turn them off. But if your aim is meeting some kind of standard, then 
other events are required.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Default logging with no rules
  2020-11-19 14:34 ` Steve Grubb
@ 2020-11-19 14:59   ` Andreas Hasenack
  0 siblings, 0 replies; 3+ messages in thread
From: Andreas Hasenack @ 2020-11-19 14:59 UTC (permalink / raw)
  To: Linux-audit

Hi,

On Thu, Nov 19, 2020 at 11:34 AM Steve Grubb <sgrubb@redhat.com> wrote:
>
> On Thursday, November 19, 2020 9:04:24 AM EST Andreas Hasenack wrote:
> > I read in an old presentation (~2011) that these come from "trusted
> > apps",
>
> There are only 10 - 15 apps that are "trusted apps". They are logging events
> that are required by various security standards such as common criteria, DISA
> STIG, PCI DSS, etc.
>
> > and in fact any process with cap_audit_write (iirc) can log
> > such events.
>
> While that may be true, it is generally not the case that they do in fact
> log.
>
> > The tip was that exclude/never list/action could be used to reduce this
> > noise, is that still the case and recommended approach?
>
> If you must, sure. Trusted app events are in the 1100-1199 range. But which
> app is causing the problems that you see? In the past, we had to silence
> crond because it was noisy.

cron is one, for sure. Everytime it fires, it's a sequence of
USER_ACCT, CRED_ACQ, LOGIN, USER_START, CRED_DISP, USER_END. And it
doesn't really log useful information either, like the job it ran. The
syslog entry is more useful for that. In this example, I had a
/bin/true root crontab:
----
type=USER_ACCT msg=audit(11/19/20 14:44:01.418:368) : pid=32715
uid=root auid=unset ses=unset msg='op=PAM:accounting acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=CRED_ACQ msg=audit(11/19/20 14:44:01.418:369) : pid=32715
uid=root auid=unset ses=unset msg='op=PAM:setcred acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=LOGIN msg=audit(11/19/20 14:44:01.418:370) : pid=32715 uid=root
old-auid=unset auid=root tty=(none) old-ses=4294967295 ses=6 res=yes
----
type=USER_START msg=audit(11/19/20 14:44:01.418:371) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:session_open acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=CRED_DISP msg=audit(11/19/20 14:44:01.422:372) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:setcred acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----
type=USER_END msg=audit(11/19/20 14:44:01.422:373) : pid=32715
uid=root auid=root ses=6 msg='op=PAM:session_close acct=root
exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success'
----

Another one is k8s apparently reapplying the iptables rules
frequently, so I get SYSCALL for setsockopt() with IPT_SO_SET_REPLACE
and NETFILTER_CFG entries. These perhaps I could turn off based on who
is emitting them via "exe=/foo/bar" and/or userid, as I can see this
happening very frequently as containers come and go.

>
> > Or is there a way to use audit with only the rules defined in /etc/audit/
> > rules.d?
>
> The rules in that dir are insufficient to fulfill regulatory requirements. If
> you are doing some kind of syscall experiment, then I can see that you might
> want to turn them off. But if your aim is meeting some kind of standard, then
> other events are required.

No standard or regulatory requirement required, I was just looking at
another layer of security to watch for specific events for which I
would create rules.

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-11-19 15:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-19 14:04 Default logging with no rules Andreas Hasenack
2020-11-19 14:34 ` Steve Grubb
2020-11-19 14:59   ` Andreas Hasenack

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.