[GIT PULL] Audit patches for v4.14
by Paul Moore
Hi Linus,
A small pull request for audit this time, only four patches and only
two with any real code changes. Those two changes are the removal of
a pointless SELinux AVC initialization audit event and a fix to
improve the audit timestamp overhead. The other two patches are
comment cleanup and administrative updates, nothing very exciting.
Everything passes our tests so please merge for v4.14.
Thanks,
-Paul
---
The following changes since commit 569dbb88e80deb68974ef6fdd6a13edb9d686261:
Linux 4.13 (2017-09-03 13:56:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git \
tags/audit-pr-20170907
for you to fetch changes up to 196a5085592c62ffa4eb739d7ce49c040c2953a1:
audit: update the function comments (2017-09-05 09:46:59 -0400)
----------------------------------------------------------------
audit/stable-4.14 PR 20170907
----------------------------------------------------------------
Geliang Tang (1):
audit: update the function comments
Mel Gorman (1):
audit: Reduce overhead using a coarse clock
Paul Moore (1):
audit: update the audit info in MAINTAINERS
Richard Guy Briggs (1):
selinux: remove AVC init audit log message
MAINTAINERS | 7 ++++---
kernel/audit.c | 4 ++--
kernel/auditsc.c | 20 ++++++++++----------
security/selinux/avc.c | 2 --
4 files changed, 16 insertions(+), 17 deletions(-)
--
paul moore
www.paul-moore.com
7 years, 1 month
Auditing console access
by Maupertuis Philippe
Hi,
The examples found in the audit documentation mention that to work it is assumed that no direct root login is allowed.
This very sensible and not a big problem except for console access.
What would be the best way to monitor what is done through this access ?
Would you recommend to forbid root access even in console ?
Philippe
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
7 years, 1 month
[PATCH] audit: reserve a numerical code for AUDIT_ANOM_PATCHED
by Vegard Nossum
A few years ago, I suggested a feature dubbed "known exploit detection".
This feature defines an interface that allows kernel developers to add
a tripwire for somebody who tries to exploit a known security hole in
older versions of the kernel. See [1] for an article and the original
discussion.
[1]: https://lwn.net/Articles/577432/
Due to the somewhat controversial nature of this feature, I never pushed
very hard for it to go upstream. However, regardless of whether this code
ever makes it upstream, it would still be useful to reserve a numerical
code for the audit message in order to ensure that private deployments
never conflicts with future upstream kernels.
I hereby request the reservation of AUDIT_ANOM_PATCHED as code 1703. This
message should be used when userspace makes a request which in previous
(unpatched) versions of the kernel would have allowed the process to
illicitly gain privileges (e.g. arbitrary code execution, etc.).
Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
---
include/uapi/linux/audit.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 0714a66f0e0c..7813efc09480 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -139,6 +139,7 @@
#define AUDIT_ANOM_PROMISCUOUS 1700 /* Device changed promiscuous mode */
#define AUDIT_ANOM_ABEND 1701 /* Process ended abnormally */
#define AUDIT_ANOM_LINK 1702 /* Suspicious use of file links */
+#define AUDIT_ANOM_PATCHED 1703 /* Patched security vulnerability */
#define AUDIT_INTEGRITY_DATA 1800 /* Data integrity verification */
#define AUDIT_INTEGRITY_METADATA 1801 /* Metadata integrity verification */
#define AUDIT_INTEGRITY_STATUS 1802 /* Integrity enable status */
--
2.12.0.rc0
7 years, 1 month
[PATCH] docs: add exclude filter never note
by Richard Guy Briggs
The exclude filter defaults to "never", ignoring the action. Make a note of
that to clarify the sense and intent of the filter.
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
docs/audit.rules.7 | 2 +-
docs/audit_add_rule_data.3 | 2 +-
docs/auditctl.8 | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/audit.rules.7 b/docs/audit.rules.7
index 192d42f..042c7dc 100644
--- a/docs/audit.rules.7
+++ b/docs/audit.rules.7
@@ -40,7 +40,7 @@ The exit filter is the place where all syscall and file system audit requests ar
The user filter is used to filter (remove) some events that originate in user space. By default, any event originating in user space is allowed. So, if there are some events that you do not want to see, then this is a place where some can be removed. See auditctl(8) for fields that are valid.
-The exclude filter is used to exclude certain events from being emitted. The msgtype field is used to tell the kernel which message types you do not want to record. This filter can remove the event as a whole and is not selective about any other attribute. The user and exit filters are better suited to selectively auditing events.
+The exclude filter is used to exclude certain events from being emitted. The msgtype and a number of subject attribute fields can be used to tell the kernel which message types you do not want to record. This filter can remove the event as a whole and is not selective about any other attribute. The user and exit filters are better suited to selectively auditing events. The action is ignored for this filter, defaulting to "never".
Syscall rules take the general form of:
diff --git a/docs/audit_add_rule_data.3 b/docs/audit_add_rule_data.3
index a0802c0..3e9039d 100644
--- a/docs/audit_add_rule_data.3
+++ b/docs/audit_add_rule_data.3
@@ -21,7 +21,7 @@ AUDIT_FILTER_TASK - Apply rule at task creation (not syscall). This is the task
AUDIT_FILTER_EXIT - Apply rule at syscall exit. This is the main filter that is used for syscalls and filesystem watches. Normally all syscall do not trigger events, so this is normally used to specify events that are of interest.
.TP
\(bu
-AUDIT_FILTER_TYPE - Apply rule at audit_log_start. This is the exclude filter which discards any records that match.
+AUDIT_FILTER_TYPE - Apply rule at audit_log_start. This is the exclude filter which discards any records that match. The action type is ignored for this filter, defaulting to "never".
.LP
.PP
diff --git a/docs/auditctl.8 b/docs/auditctl.8
index 05e389e..88466de 100644
--- a/docs/auditctl.8
+++ b/docs/auditctl.8
@@ -81,7 +81,7 @@ Add a rule to the syscall exit list. This list is used upon exit from a system c
Add a rule to the user message filter list. This list is used by the kernel to filter events originating in user space before relaying them to the audit daemon. It should be noted that the only fields that are valid are: uid, auid, gid, pid, subj_user, subj_role, subj_type, subj_sen, subj_clr, and msgtype. All other fields will be treated as non-matching. It should be understood that any event originating from user space from a process that has CAP_AUDIT_WRITE will be recorded into the audit trail. This means that the most likely use for this filter is with rules that have an action of never since nothing has to be done to allow events to be recorded.
.TP
.B exclude
-Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, message type or subject context
+Add a rule to the event type exclusion filter list. This list is used to filter events that you do not want to see. For example, if you do not want to see any avc messages, you would using this list to record that. Events can be excluded by process ID, user ID, group ID, login user ID, message type or subject context. The action is ignored and uses its default of "never".
.RE
The following describes the valid \fIactions\fP for the rule:
--
1.7.1
7 years, 1 month
FYI: rebasing audit/next
by Paul Moore
Hello all,
Currently the audit/next branch is based on v4.11, considering some of
the work is that currently being proposed for after this current merge
window, now is a good time to rebase the branch. I'm going to rebase
now, repeat the upstream testing, and if all goes well I'll send
audit/next up to Linus later this week.
--
paul moore
www.paul-moore.com
7 years, 1 month
[PATCH V3 00/10] capabilities: do not audit log BPRM_FCAPS on set*id
by Richard Guy Briggs
The audit subsystem is adding a BPRM_FCAPS record when auditing setuid
application execution (SYSCALL execve). This is not expected as it was
supposed to be limited to when the file system actually had capabilities
in an extended attribute. It lists all capabilities making the event
really ugly to parse what is happening. The PATH record correctly
records the setuid bit and owner. Suppress the BPRM_FCAPS record on
set*id.
See: https://github.com/linux-audit/audit-kernel/issues/16
The first to eighth just massage the logic to make it easier to understand.
Some of them could be squashed together.
The patch that resolves this issue is the ninth.
It would be possible to address the original issue with a change of
"!uid_eq(new->euid, root_uid) || !uid_eq(new->uid, root_uid)"
to
"!(uid_eq(new->euid, root_uid) || uid_eq(new->uid, root_uid))"
but it took me long enough to understand this logic that I don't think I'd be
doing any favours by leaving it this difficult to understand.
The final patch attempts to address all the conditions that need logging based
on mailing list conversations, recoginizing there is probably some duplication
in the logic.
Richard Guy Briggs (10):
capabilities: factor out cap_bprm_set_creds privileged root
capabilities: intuitive names for cap gain status
capabilities: rename has_cap to has_fcap
capabilities: use root_priveleged inline to clarify logic
capabilities: use intuitive names for id changes
capabilities: move audit log decision to function
capabilities: remove a layer of conditional logic
capabilities: invert logic for clarity
capabilities: fix logic for effective root or real root
capabilities: audit log other surprising conditions
security/commoncap.c | 166 ++++++++++++++++++++++++++++++++------------------
1 files changed, 107 insertions(+), 59 deletions(-)
7 years, 1 month
how to audit auditd itself ?
by Maupertuis Philippe
Hi,
The 30-pci-dss-v31.rules in the doc directory contains the following statement :
## 10.2.6 Verify the following are logged:
## Initialization of audit logs
## Stopping or pausing of audit logs.
## These are handled implicitly by auditd
This very good since nothing need to be done, but how can I actually find when these events occur ?
I am not sure what means "pausing of audit logs", can we really "pause" auditd ?
Philippe
!!!*************************************************************************************
"Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"
7 years, 2 months
