* Re: Auditing Logons/Logoffs
[not found] ` <CAJdJdQmJb44ZwCWYxR9Cry9XddsqwR5_F5cbLyjTeDF7iVs0mQ@mail.gmail.com>
@ 2017-07-17 15:26 ` Steve Grubb
0 siblings, 0 replies; 3+ messages in thread
From: Steve Grubb @ 2017-07-17 15:26 UTC (permalink / raw)
To: warron.french; +Cc: linux-audit
On Friday, July 14, 2017 5:18:13 PM EDT warron.french wrote:
> OK, so no rules to be found specifically/explicitly in audit.rules (for
> RHEL6 nor RHEL7) because it is hardwired/embedded in the code of auditd
> already?
Not auditd. In whatever observes the event. Pam observes the login for sshd
and it creates/sends the event.
> Looks like if I run an aureport and see the summary it might imply what is
> tracked by default and then I can deduce beyond that reasonably that:
It would be a fraction of what is hardwired since its based on system
activity. If you never run newgrp, then you will never see that event.
> 1. I either have a rule for something in audit.rules that is being
> summarized by aureport, and
> 2. can then attempt an ausearch of some appropriate context against the
> "test" that I need to validate.
>
> For example, User account modification, creation, deletion, suspensions and
> lockings might be covered as summarized by aureport under the category
> of - *Number of changes to accounts, groups, or roles:*
Locking would be under the anomaly category. Please see the explanation in
"User Login Lifecycle Events"
> Is that an appropriate assessment?
>
> If not, what do I need to do to address AUDIT(B) and AUDIT(C) tests?
They are generated automatically. You don't need to do anything for them.
> Thank you again, in advance. If you have something definitive I will read
> it, I just don't know how to look for these concepts apparently.
I already pointed you to the reading material. The specifications are written
to explain when certain hardwired event should be sent and what they mean.
Hardwired events mostly come from user space and never have a syscall record
attached. They also never have a key field.
-Steve
> On Fri, Jul 14, 2017 at 4:46 PM, Steve Grubb <sgrubb@redhat.com> wrote:
> > On Friday, July 14, 2017 3:51:16 PM EDT warron.french wrote:
> > > Back to this again, as I thought my coworker had addressed it months
> > > ago,
> > > but he did not as I cannot find anything.
> > >
> > > *THE_SUBJECT*: Auditing Logons and Logoffs (success/failures)
> > >
> > > I am aware of the following files:
> > > /var/log/faillog, and
> > > /var/log/lastlog
> > >
> > > The following link is relevant to RHEL5 (maybe 6 and 7??):
> > > https://www.stigviewer.com/stig/oracle_linux_5/2015-12-07/finding/V-818
> > >
> > > Is there an appropriate syscall for handling *THE_SUBJECT*?
> >
> > Nope. This is hardwired into the applications. There is a specification
> > here:
> >
> > https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Login-> > Lifecycle-Events
> >
> > That explains each event that is part of the login and logout and its
> > meaning.
> >
> > > Do I use the syntax as advised in the link provided at stigviewer.com?
> >
> > Nope. Its hardwired. As long as audit is enabled, you'll get them.
> >
> > -Steve
> >
> > > We are dealing with systems that do tie into IPA, but have to ensure
> > > *THE_SUBJECT* is being addressed and forwarded.
> > >
> > > I have to support both RHEL6 and RHEL7.
> > >
> > >
> > > Thanks in advance,
> > > --------------------------
> > > Warron French
^ permalink raw reply [flat|nested] 3+ messages in thread