Re: Auditing Logons/Logoffs
by Steve Grubb
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(a)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
7 years, 12 months
AUDIT(C) - Group/Role addition, deletion modification
by warron.french
Same as AUDIT(B) only for roles and groups?
Simply put a watch rule on /etc/group and /etc/gshadow?
Is that really enough? Do I also monitor the executables for /bin/passwd,
/sbin/{groupadd, groupdel, groupmod, usermod}?
Usermod, because technically, you can affect memberships of a user with
this command and also useradd?
Is *that *suitable?
Is there an appropriate syscall for AUDIT(C)?
--------------------------
Warron French
8 years
AUDIT(B) - USER add, delete, modify, suspend and lock
by warron.french
Similar idea to the prior email:
I need to monitor local user account
*creation, modification, deletion, suspension and locking.*
I know that I can monitor: */etc/passwd, /etc/group, /etc/shadow* and
*/etc/gshadow*, but how do I monitor who modified wfrench inside
/etc/passwd?
Is:
*-w /etc/passwd -k monitor_account_manipulations*
Good enough?
--------------------------
Warron French
8 years
Auditing Logons/Logoffs
by warron.french
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*?
Do I use the syntax as advised in the link provided at stigviewer.com?
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
8 years
message type dictionary clarifications
by Richard Guy Briggs
Hi,
In the process of updating the audit message type dictionary, I came
across a couple of differences I wanted to clear up.
The descriptions in the userspace header file don't obviously line up
with another source. Can I get a clarification on these two messages:
AUDIT_USER_ACCT 1101 User system access authorization
Alt: User account modification
AUDIT_USER_MGMT 1102 User account attribute change
Alt: Userspace management data
Similarly, these weren't clear to me as to whether they were active or
passive reports. Do these records say that the RESPonse happenned, or
that the RESPonse should happen?
AUDIT_RESP_ALERT 2201 Alert email was sent
AUDIT_RESP_ANOMALY 2200 Anomaly not reacted to
AUDIT_RESP_EXEC 2210 Execute a script
AUDIT_RESP_HALT 2212 take the system down
AUDIT_RESP_KILL_PROC 2202 Kill program
AUDIT_RESP_SEBOOL 2209 Set an SELinux boolean
AUDIT_RESP_SINGLE 2211 Go to single user mode
AUDIT_RESP_TERM_ACCESS 2203 Terminate session
AUDIT_RESP_TERM_LOCK 2208 Terminal was locked
In particular, does AUDIT_RESP_EXEC mean something as simple as a script
was executed in response to some detected event, or intrusion detection
program responds to a threat originating from the execution of a
program? I suspect they are all active and this EXEC one means a script
was executed in response.
Thanks!
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
8 years
ausearch message type omissions
by Richard Guy Briggs
Hi,
In the process of creating/updating the audit message/record type
dictionary, I stumbled on the following two message types missing from
ausearch -m text:
This one is in the userspace header file. What is its meaning and is it
a printable record?
AUDIT_DAEMON_RECONFIG,1204,Auditd should reconfigure
This was added to test if a daemon was still listening and should be
logged that an attempt was made to replace it.
AUDIT_REPLACE,1329,Replace auditd if this probe unanswerd
Thanks!
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
8 years
Audit message dictionary
by Richard Guy Briggs
Hi,
I've created an audit message dictionary along the lines of the existing
audit field dictionary to add to the github audit documentation
repository.
It is checked in to:
https://github.com/linux-audit/audit-documentation/blob/master/specs/mess...
related to issue:
https://github.com/linux-audit/audit-documentation/issues/21
This is a preliminary commit that was created from userspace'
lib/libaudit.h and kernel's include/uapi/linux/audit.h, merging, sorting
and removing duplicates and verifying I've not missed anything obvious
from ausearch.
It might be useful to find a way to add the message range descriptions
to this CSV file, or to add them to another file in the same directory.
Comments, fixes and additions welcome.
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
8 years
Re: [PATCH] audit: Reduce overhead using a coarse clock
by Paul Moore
On Tue, Jul 4, 2017 at 3:41 PM, Deepa Dinamani <deepa.kernel(a)gmail.com> wrote:
> On Tue, Jul 4, 2017 at 12:20 PM, Arnd Bergmann <arnd(a)arndb.de> wrote:
>> On Tue, Jul 4, 2017 at 2:11 PM, Mel Gorman <mgorman(a)techsingularity.net> wrote:
>>>
>>> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net>
>>
>> Acked-by: Arnd Bergmann <arnd(a)arndb.de>
>
> Acked-by: Deepa Dinamani <deepa.kernel(a)gmail.com>
>
> As already Arnd pointed out, your patch should be fine as that is how
> it was before my patch. Since nobody saw any problems before my patch,
> lower granularity should be fine.
Agreed. Mel's patch basically restores the previous behavior while
keeping the 64-bit timestamp size.
Considering where we are at with the merge window, I'm going to merge
this into the audit/next branch and not send this up to Linus during
the current window; while the patch is small, I like to give things
some time in linux-next before sending them up.
--
paul moore
www.paul-moore.com
8 years
[PATCH 00/15] v2 kernel core refcount conversions
by Elena Reshetova
Changes in v2:
* dropped already merged patches
* rebase on top of linux-next/master
* Now by default refcount_t = atomic_t (*) and uses all atomic
standard operations unless CONFIG_REFCOUNT_FULL is enabled.
This is a compromise for the systems that are critical on
performance (such as net) and cannot accept even slight delay
on the refcounter operations.
This series, for core kernel components, replaces atomic_t reference
counters with the new refcount_t type and API (see include/linux/refcount.h).
By doing this we prevent intentional or accidental
underflows or overflows that can led to use-after-free vulnerabilities.
The patches are fully independent and can be cherry-picked separately.
If there are no objections to the patches, please merge them via respective trees.
If you want to test with refcount_t protection enabled, CONFIG_REFCOUNT_FULL
must be enabled.
* The respective change is currently merged into -next as
"locking/refcount: Create unchecked atomic_t implementation".
Elena Reshetova (15):
kernel: convert sighand_struct.count from atomic_t to refcount_t
kernel: convert signal_struct.sigcnt from atomic_t to refcount_t
kernel: convert user_struct.__count from atomic_t to refcount_t
kernel: convert task_struct.usage from atomic_t to refcount_t
kernel: convert task_struct.stack_refcount from atomic_t to refcount_t
kernel: convert perf_event_context.refcount from atomic_t to
refcount_t
kernel: convert ring_buffer.refcount from atomic_t to refcount_t
kernel: convert ring_buffer.aux_refcount from atomic_t to refcount_t
kernel: convert uprobe.ref from atomic_t to refcount_t
kernel: convert nsproxy.count from atomic_t to refcount_t
kernel: convert group_info.usage from atomic_t to refcount_t
kernel: convert cred.usage from atomic_t to refcount_t
kernel: convert numa_group.refcount from atomic_t to refcount_t
kernel: convert futex_pi_state.refcount from atomic_t to refcount_t
kernel: convert kcov.refcount from atomic_t to refcount_t
fs/exec.c | 4 ++--
fs/proc/task_nommu.c | 2 +-
include/linux/cred.h | 13 ++++++------
include/linux/init_task.h | 7 +++---
include/linux/nsproxy.h | 6 +++---
include/linux/perf_event.h | 3 ++-
include/linux/sched.h | 5 +++--
include/linux/sched/signal.h | 5 +++--
include/linux/sched/task.h | 4 ++--
include/linux/sched/task_stack.h | 2 +-
include/linux/sched/user.h | 5 +++--
kernel/cred.c | 46 ++++++++++++++++++++--------------------
kernel/events/core.c | 18 ++++++++--------
kernel/events/internal.h | 5 +++--
kernel/events/ring_buffer.c | 8 +++----
kernel/events/uprobes.c | 8 +++----
kernel/fork.c | 24 ++++++++++-----------
kernel/futex.c | 13 ++++++------
kernel/groups.c | 2 +-
kernel/kcov.c | 9 ++++----
kernel/nsproxy.c | 6 +++---
kernel/sched/fair.c | 8 +++----
kernel/user.c | 8 +++----
23 files changed, 110 insertions(+), 101 deletions(-)
--
2.7.4
8 years
A note on the audit kernel next branch
by Paul Moore
Hello all,
Since I think there is a reasonable chance we are going to see more
capability auditing patches hit the audit/next branch during the
upcoming development cycle I'm going to refrain from the usual rebase
of the audit/next branch. Since the branch is currently based on
v4.11 I doubt this will have a significant impact, but if it does we
can reevaluate the base of the branch at a later date.
--
paul moore
www.paul-moore.com
8 years
