[PATCH] audit: always enable syscall auditing when supported and audit is enabled
by Paul Moore
To the best of our knowledge, everyone who enables audit at compile
time also enables syscall auditing; this patch simplifies the Kconfig
menus by removing the option to disable syscall auditing when audit
is selected and the target arch supports it.
Signed-off-by: Paul Moore <pmoore(a)redhat.com>
---
init/Kconfig | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index c24b6f7..d4663b1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -299,20 +299,15 @@ config AUDIT
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
- logging of avc messages output). Does not do system-call
- auditing without CONFIG_AUDITSYSCALL.
+ logging of avc messages output). System call auditing is included
+ on architectures which support it.
config HAVE_ARCH_AUDITSYSCALL
bool
config AUDITSYSCALL
- bool "Enable system-call auditing support"
+ def_bool y
depends on AUDIT && HAVE_ARCH_AUDITSYSCALL
- default y if SECURITY_SELINUX
- help
- Enable low-overhead system-call auditing infrastructure that
- can be used independently or with another kernel subsystem,
- such as SELinux.
config AUDIT_WATCH
def_bool y
6 years
Limiting SECCOMP audit events
by Steve Grubb
Hello,
Over the last month, the amount of seccomp events in audit logs is sky-rocketing. I
have over a million events in the last 2 days. Most of this is generated by firefox and
qt webkit.
I am wondering if the audit package should ship a file for
/usr/lib/sysctl.d/60-auditd.conf
wherein it has
kernel.seccomp.actions_logged = kill_process kill_thread errno
Also, has anyone verified this sysctl is filtering audit events? Even with the above, I
have over a million events on a 4.14.3 kernel. Firefox alone is generating over
50,000 events per hour.
Thanks,
-Steve
6 years, 9 months
RFC(V3): Audit Kernel Container IDs
by Richard Guy Briggs
Containers are a userspace concept. The kernel knows nothing of them.
The Linux audit system needs a way to be able to track the container
provenance of events and actions. Audit needs the kernel's help to do
this.
Since the concept of a container is entirely a userspace concept, a
registration from the userspace container orchestration system initiates
this. This will define a point in time and a set of resources
associated with a particular container with an audit container
identifier.
The registration is a u64 representing the audit container identifier
written to a special file in a pseudo filesystem (proc, since PID tree
already exists) representing a process that will become a parent process
in that container. This write might place restrictions on mount
namespaces required to define a container, or at least careful checking
of namespaces in the kernel to verify permissions of the orchestrator so
it can't change its own container ID. A bind mount of nsfs may be
necessary in the container orchestrator's mount namespace. This write
can only happen once per process.
Note: The justification for using a u64 is that it minimizes the
information printed in every audit record, reducing bandwidth and limits
comparisons to a single u64 which will be faster and less error-prone.
Require CAP_AUDIT_CONTROL to be able to carry out the registration. At
that time, record the target container's user-supplied audit container
identifier along with a target container's parent process (which may
become the target container's "init" process) process ID (referenced
from the initial PID namespace) in a new record AUDIT_CONTAINER with a
qualifying op=$action field.
Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid
container ID present on an auditable action or event.
Forked and cloned processes inherit their parent's audit container
identifier, referenced in the process' task_struct. Since the audit
container identifier is inherited rather than written, it can still be
written once. This will prevent tampering while allowing nesting.
(This can be implemented with an internal settable flag upon
registration that does not get copied across a fork/clone.)
Mimic setns(2) and return an error if the process has already initiated
threading or forked since this registration should happen before the
process execution is started by the orchestrator and hence should not
yet have any threads or children. If this is deemed overly restrictive,
switch all of the target's threads and children to the new containerID.
Trust the orchestrator to judiciously use and restrict CAP_AUDIT_CONTROL.
When a container ceases to exist because the last process in that
container has exited log the fact to balance the registration action.
(This is likely needed for certification accountability.)
At this point it appears unnecessary to add a container session
identifier since this is all tracked from loginuid and sessionid to
communicate with the container orchestrator to spawn an additional
session into an existing container which would be logged. It can be
added at a later date without breaking API should it be deemed
necessary.
The following namespace logging actions are not needed for certification
purposes at this point, but are helpful for tracking namespace activity.
These are auxilliary records that are associated with namespace
manipulation syscalls unshare(2), clone(2) and setns(2), so the records
will only show up if explicit syscall rules have been added to document
this activity.
Log the creation of every namespace, inheriting/adding its spawning
process' audit container identifier(s), if applicable. Include the
spawning and spawned namespace IDs (device and inode number tuples).
[AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)]
Note: At this point it appears only network namespaces may need to track
container IDs apart from processes since incoming packets may cause an
auditable event before being associated with a process. Since a
namespace can be shared by processes in different containers, the
namespace will need to track all containers to which it has been
assigned.
Upon registration, the target process' namespace IDs (in the form of a
nsfs device number and inode number tuple) will be recorded in an
AUDIT_NS_INFO auxilliary record.
Log the destruction of every namespace that is no longer used by any
process, including the namespace IDs (device and inode number tuples).
[AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)]
Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action)
the parent and child namespace IDs for any changes to a process'
namespaces. [setns(2)]
Note: It may be possible to combine AUDIT_NS_* record formats and
distinguish them with an op=$action field depending on the fields
required for each message type.
The audit container identifier will need to be reaped from all
implicated namespaces upon the destruction of a container.
This namespace information adds supporting information for tracking
events not attributable to specific processes.
Changelog:
(Upstream V3)
- switch back to u64 (from pmoore, can be expanded to u128 in future if
need arises without breaking API. u32 was originally proposed, up to
c36 discussed)
- write-once, but children inherit audit container identifier and can
then still be written once
- switch to CAP_AUDIT_CONTROL
- group namespace actions together, auxilliary records to namespace
operations.
(Upstream V2)
- switch from u64 to u128 UUID
- switch from "signal" and "trigger" to "register"
- restrict registration to single process or force all threads and
children into same container
- 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
7 years
No audit patches for v4.16
by Paul Moore
Hello all,
As the audit/next branch is empty, there isn't going to be a pull
request for the 4.16 merge window. Because of this, I'm going to take
the opportunity to go ahead and rebase audit/next to v4.15; hopefully
this doesn't mess up any work in progress, if it does let me know and
we can work something out.
--
paul moore
www.paul-moore.com
7 years
Remote Logging of auditd
by Joshua Ammons
Hi All,
I wanted to send this out to see if anyone has encountered this situation before and, if so, how you handled it. We send our auditd logs to a remote central logging server. Is there any way to decode the hex encoded fields before sending them along? Similar to the ausearch [-i] flag which interprets the encoded value?
For example, the "data" field in a USER_TTY event:
type=USER_TTY msg=audit(1516365981.138:13125): pid=7161 uid=0 auid=1007 ses=65 data=73657276696365206175646974642073746F70
type=USER_TTY msg=audit(1516367294.919:13331): pid=7161 uid=0 auid=1007 ses=65 data=73797374656D63746C2073746F7020617564697464
type=USER_TTY msg=audit(1516367648.904:13375): pid=7161 uid=0 auid=1007 ses=65 data=6964206A6F7368616D6D6F6E73
type=USER_TTY msg=audit(1516367664.832:13378): pid=7161 uid=0 auid=1007 ses=65 data=636174202F6574632F706173737764207C2067726570206A6F7368616D6D6F6E73
type=USER_TTY msg=audit(1516367715.041:13388): pid=7161 uid=0 auid=1007 ses=65 data=636174202F7661722F6C6F672F61756469742F61756469742E6C6F67207C20677265702022555345525F54545922
We have the following configured in our /etc/rsyslog.conf file:
:programname, isequal, "audispd" @SERVER_NAME:514
:programname, isequal, "auditd" @SERVER_NAME:514
^^ This, however, will send those fields in their raw format and does not decode the values. Is it possible to natively interpret those fields before sending them to the remote server?
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
7 years
RE: auditd configuration for PCI DSS 10.2.x Compliance
by Joshua Ammons
Hello All,
Just thought I'd give this one more shot to see if anyone had any comments on my prior message (see below)? Any input you have would be greatly appreciated. I won't bother the group any more on this topic.
Thank you!
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons(a)walmart.com
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image001.png@01D38DDE.1EEEA9D0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
From: Joshua Ammons
Sent: Thursday, January 11, 2018 4:33 PM
To: 'linux-audit(a)redhat.com' <linux-audit(a)redhat.com>
Subject: auditd configuration for PCI DSS 10.2.x Compliance
Hello,
I was wondering if anyone had any experience putting together an auditd configuration to meet PCI DSS 10.2.x requirements? Below are the requirements and my thoughts for each one...if anyone has anything that they have done I'd love to hear it!
10.2.2 All actions taken by any individual with root or administrative privileges
* Enable the pam_tty_audit.so shared library in /etc/pam.d/[su/sudo/sudo-i/su-l] files.
o USER_TTY event type will contain all commands from privileged user.
* Add following lines to /etc/audit/rules.d/audit.rules file:
o # Audit all actions by any individual with root or administrative privileges
o -a exit,always -F arch=b64 -F euid=0 -S execve -k root-commands
o -a exit,always -F arch=b32 -F euid=0 -S execve -k root-commands
? EXECVE event type will contain all commands from user with elevated privileges.
? Question: with the pam_tty_audit.so enabled, and those commands being logged to USER_TTY events...is this rule needed also?
10.2.3 Access to all audit trails
* I'm not sure the best route to cover this one. If I add a rule to watch /var/log/* for 'wa' actions, those logs are constantly being written to so that would be too noisy I believe. Does anyone know how I would form a rule that would fire when a file within /var/log is accessed directly by a user? Also, if the user makes any manual changes, such as deleting a file or modifying its contents?
10.2.4 Invalid logical access attempts
* Based on my understanding, this wouldn't really be covered by auditd, but by the standard authpriv facility. Anybody configure anything in auditd to cover this requirement?
10.2.5 Use of and changes to identification and authentication mechanisms-including but not limited to creation of new accounts and elevation of privileges-and all changes, additions, or deletions to accounts with root or administrative privileges
* CRED_ACQ (sudo) and USER_AUTH (su) events should contain when a user sudo's or su's to privileged account. My understanding is that these would not require any extra rules to be written. However, I'm not quite sure how to handle the requirements to log creation of new accounts, and all changes, or deletions to accounts with root/admin privileges...any ideas?
10.2.6. Initialization, stopping, or pausing of the audit logs
* Auditd:
o DAEMON_END events would indicate auditd was stopped.
o DAEMON_START and SERVICE_START events would indicate when auditd initialized.
o Anything else anybody would add here?
* Rsyslog:
o SERVICE_START event (unit=rsyslog) when rsyslog is initialized
o SERVICE_STOP event (unit=rsyslog) when rsyslog is stopped
o Anything else anybody would add here?
10.2.7 Creation and deletion of system- level objects
* -w [DIRECTORY] -p wa rules for the directories below:
o /bin
o /sbin
o /usr/bin
o /usr/sbin
o /var/lib
o /usr/lib
o /usr/libexec
o /lib64
o /usr/lib64
? Would the above cover this requirement? Any other suggestions here?
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons(a)walmart.com<mailto:Joshua.Ammons@walmart.com>
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image002.png@01D38DDE.1EEEA9D0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
7 years
auditd configuration for PCI DSS 10.2.x Compliance
by Joshua Ammons
Hello,
I was wondering if anyone had any experience putting together an auditd configuration to meet PCI DSS 10.2.x requirements? Below are the requirements and my thoughts for each one...if anyone has anything that they have done I'd love to hear it!
10.2.2 All actions taken by any individual with root or administrative privileges
* Enable the pam_tty_audit.so shared library in /etc/pam.d/[su/sudo/sudo-i/su-l] files.
o USER_TTY event type will contain all commands from privileged user.
* Add following lines to /etc/audit/rules.d/audit.rules file:
o # Audit all actions by any individual with root or administrative privileges
o -a exit,always -F arch=b64 -F euid=0 -S execve -k root-commands
o -a exit,always -F arch=b32 -F euid=0 -S execve -k root-commands
? EXECVE event type will contain all commands from user with elevated privileges.
? Question: with the pam_tty_audit.so enabled, and those commands being logged to USER_TTY events...is this rule needed also?
10.2.3 Access to all audit trails
* I'm not sure the best route to cover this one. If I add a rule to watch /var/log/* for 'wa' actions, those logs are constantly being written to so that would be too noisy I believe. Does anyone know how I would form a rule that would fire when a file within /var/log is accessed directly by a user? Also, if the user makes any manual changes, such as deleting a file or modifying its contents?
10.2.4 Invalid logical access attempts
* Based on my understanding, this wouldn't really be covered by auditd, but by the standard authpriv facility. Anybody configure anything in auditd to cover this requirement?
10.2.5 Use of and changes to identification and authentication mechanisms-including but not limited to creation of new accounts and elevation of privileges-and all changes, additions, or deletions to accounts with root or administrative privileges
* CRED_ACQ (sudo) and USER_AUTH (su) events should contain when a user sudo's or su's to privileged account. My understanding is that these would not require any extra rules to be written. However, I'm not quite sure how to handle the requirements to log creation of new accounts, and all changes, or deletions to accounts with root/admin privileges...any ideas?
10.2.6. Initialization, stopping, or pausing of the audit logs
* Auditd:
o DAEMON_END events would indicate auditd was stopped.
o DAEMON_START and SERVICE_START events would indicate when auditd initialized.
o Anything else anybody would add here?
* Rsyslog:
o SERVICE_START event (unit=rsyslog) when rsyslog is initialized
o SERVICE_STOP event (unit=rsyslog) when rsyslog is stopped
o Anything else anybody would add here?
10.2.7 Creation and deletion of system- level objects
* -w [DIRECTORY] -p wa rules for the directories below:
o /bin
o /sbin
o /usr/bin
o /usr/sbin
o /var/lib
o /usr/lib
o /usr/libexec
o /lib64
o /usr/lib64
? Would the above cover this requirement? Any other suggestions here?
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons(a)walmart.com
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image002.png@01D38AF9.D79607E0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
7 years
type=PROCTITLE events not being populated in /var/log/audit/audit.log
by Joshua Ammons
Hello,
I wanted to check if anyone was aware of a setting on RedHat box for enabling the PROCTITLE event type for audit logs? Is there any difference between RedHat and CentOS? I have one box running RedHat 7.3 and another running CentOS 7.3, with auditd enabled on both with the same rules. However, only the RedHat box is populating the event type PROCTITLE - the CentOS box does not.
I would like to get the PROCTITLE event type working on my CentOS box as well, if possible, but I cannot find any documentation online about anyone else having this issue and how to resolve.
Thanks for your time.
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons(a)walmart.com
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image003.png@01D38A31.CCC17F20]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
7 years
