[RFC PATCH ghak86 V1] audit: eliminate audit_enabled magic number comparison
by Richard Guy Briggs
Remove comparison of audit_enabled to magic numbers outside of audit.
Related: https://github.com/linux-audit/audit-kernel/issues/86
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
drivers/tty/tty_audit.c | 2 +-
include/linux/audit.h | 5 ++++-
include/net/xfrm.h | 2 +-
kernel/audit.c | 3 ---
net/netfilter/xt_AUDIT.c | 2 +-
net/netlabel/netlabel_user.c | 2 +-
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/tty_audit.c b/drivers/tty/tty_audit.c
index e30aa6b..50f567b 100644
--- a/drivers/tty/tty_audit.c
+++ b/drivers/tty/tty_audit.c
@@ -92,7 +92,7 @@ static void tty_audit_buf_push(struct tty_audit_buf *buf)
{
if (buf->valid == 0)
return;
- if (audit_enabled == 0) {
+ if (audit_enabled == AUDIT_OFF) {
buf->valid = 0;
return;
}
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 69c7847..9334fbe 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -117,6 +117,9 @@ struct audit_field {
extern void audit_log_session_info(struct audit_buffer *ab);
+#define AUDIT_OFF 0
+#define AUDIT_ON 1
+#define AUDIT_LOCKED 2
#ifdef CONFIG_AUDIT
/* These are defined in audit.c */
/* Public API */
@@ -202,7 +205,7 @@ static inline int audit_log_task_context(struct audit_buffer *ab)
static inline void audit_log_task_info(struct audit_buffer *ab,
struct task_struct *tsk)
{ }
-#define audit_enabled 0
+#define audit_enabled AUDIT_OFF
#endif /* CONFIG_AUDIT */
#ifdef CONFIG_AUDIT_COMPAT_GENERIC
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 7f2e31a..ce995a1 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -734,7 +734,7 @@ static inline struct audit_buffer *xfrm_audit_start(const char *op)
{
struct audit_buffer *audit_buf = NULL;
- if (audit_enabled == 0)
+ if (audit_enabled == AUDIT_OFF)
return NULL;
audit_buf = audit_log_start(audit_context(), GFP_ATOMIC,
AUDIT_MAC_IPSEC_EVENT);
diff --git a/kernel/audit.c b/kernel/audit.c
index e7478cb..8442c65 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -83,9 +83,6 @@
#define AUDIT_INITIALIZED 1
static int audit_initialized;
-#define AUDIT_OFF 0
-#define AUDIT_ON 1
-#define AUDIT_LOCKED 2
u32 audit_enabled = AUDIT_OFF;
bool audit_ever_enabled = !!AUDIT_OFF;
diff --git a/net/netfilter/xt_AUDIT.c b/net/netfilter/xt_AUDIT.c
index f368ee6..af883f1 100644
--- a/net/netfilter/xt_AUDIT.c
+++ b/net/netfilter/xt_AUDIT.c
@@ -72,7 +72,7 @@ static bool audit_ip6(struct audit_buffer *ab, struct sk_buff *skb)
struct audit_buffer *ab;
int fam = -1;
- if (audit_enabled == 0)
+ if (audit_enabled == AUDIT_OFF)
goto errout;
ab = audit_log_start(NULL, GFP_ATOMIC, AUDIT_NETFILTER_PKT);
if (ab == NULL)
diff --git a/net/netlabel/netlabel_user.c b/net/netlabel/netlabel_user.c
index 2f328af..4676f5b 100644
--- a/net/netlabel/netlabel_user.c
+++ b/net/netlabel/netlabel_user.c
@@ -101,7 +101,7 @@ struct audit_buffer *netlbl_audit_start_common(int type,
char *secctx;
u32 secctx_len;
- if (audit_enabled == 0)
+ if (audit_enabled == AUDIT_OFF)
return NULL;
audit_buf = audit_log_start(audit_context(), GFP_ATOMIC, type);
--
1.8.3.1
6 years, 6 months
[PATCH ghak89 V3] audit: rename FILTER_TYPE to FILTER_EXCLUDE
by Richard Guy Briggs
The AUDIT_FILTER_TYPE name is vague and misleading due to not describing
where or when the filter is applied and obsolete due to its available
filter fields having been expanded.
Userspace has already renamed it from AUDIT_FILTER_TYPE to
AUDIT_FILTER_EXCLUDE without checking if it already exists. The
userspace maintainer assures that as long as it is set to the same value
it will not be a problem since the userspace code does not treat
compiler warnings as errors. If this policy changes then checks if it
already exists can be added at the same time.
See: https://github.com/linux-audit/audit-kernel/issues/89
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
v3:
- Move macros together, update comment
v2:
- Change from AUDIT_FILTER_EXCL to AUDIT_FILTER_EXCLUDE
---
include/uapi/linux/audit.h | 3 ++-
kernel/audit.c | 2 +-
kernel/auditfilter.c | 10 +++++-----
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 04f9bd2..6cae130 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -156,7 +156,8 @@
#define AUDIT_FILTER_ENTRY 0x02 /* Apply rule at syscall entry */
#define AUDIT_FILTER_WATCH 0x03 /* Apply rule to file system watches */
#define AUDIT_FILTER_EXIT 0x04 /* Apply rule at syscall exit */
-#define AUDIT_FILTER_TYPE 0x05 /* Apply rule at audit_log_start */
+#define AUDIT_FILTER_EXCLUDE 0x05 /* Apply rule before record creation */
+#define AUDIT_FILTER_TYPE AUDIT_FILTER_EXCLUDE /* obsolete misleading naming */
#define AUDIT_FILTER_FS 0x06 /* Apply rule at __audit_inode_child */
#define AUDIT_NR_FILTERS 7
diff --git a/kernel/audit.c b/kernel/audit.c
index 3a18e59..513a10e 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1754,7 +1754,7 @@ struct audit_buffer *audit_log_start(struct audit_context *ctx, gfp_t gfp_mask,
if (audit_initialized != AUDIT_INITIALIZED)
return NULL;
- if (unlikely(!audit_filter(type, AUDIT_FILTER_TYPE)))
+ if (unlikely(!audit_filter(type, AUDIT_FILTER_EXCLUDE)))
return NULL;
/* NOTE: don't ever fail/sleep on these two conditions:
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index eaa3201..261843d 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -264,7 +264,7 @@ static inline struct audit_entry *audit_to_entry_common(struct audit_rule_data *
case AUDIT_FILTER_TASK:
#endif
case AUDIT_FILTER_USER:
- case AUDIT_FILTER_TYPE:
+ case AUDIT_FILTER_EXCLUDE:
case AUDIT_FILTER_FS:
;
}
@@ -337,7 +337,7 @@ static int audit_field_valid(struct audit_entry *entry, struct audit_field *f)
{
switch(f->type) {
case AUDIT_MSGTYPE:
- if (entry->rule.listnr != AUDIT_FILTER_TYPE &&
+ if (entry->rule.listnr != AUDIT_FILTER_EXCLUDE &&
entry->rule.listnr != AUDIT_FILTER_USER)
return -EINVAL;
break;
@@ -931,7 +931,7 @@ static inline int audit_add_rule(struct audit_entry *entry)
/* If any of these, don't count towards total */
switch(entry->rule.listnr) {
case AUDIT_FILTER_USER:
- case AUDIT_FILTER_TYPE:
+ case AUDIT_FILTER_EXCLUDE:
case AUDIT_FILTER_FS:
dont_count = 1;
}
@@ -1013,7 +1013,7 @@ int audit_del_rule(struct audit_entry *entry)
/* If any of these, don't count towards total */
switch(entry->rule.listnr) {
case AUDIT_FILTER_USER:
- case AUDIT_FILTER_TYPE:
+ case AUDIT_FILTER_EXCLUDE:
case AUDIT_FILTER_FS:
dont_count = 1;
}
@@ -1369,7 +1369,7 @@ int audit_filter(int msgtype, unsigned int listtype)
break;
}
if (result > 0) {
- if (e->rule.action == AUDIT_NEVER || listtype == AUDIT_FILTER_TYPE)
+ if (e->rule.action == AUDIT_NEVER || listtype == AUDIT_FILTER_EXCLUDE)
ret = 0;
break;
}
--
1.8.3.1
6 years, 6 months
[PATCH ghak82 v3] audit: Fix extended comparison of GID/EGID
by Ondrej Mosnacek
The audit_filter_rules() function in auditsc.c used the in_[e]group_p()
functions to check GID/EGID match, but these functions use the current
task's credentials, while the comparison should use the credentials of
the task given to audit_filter_rules() as a parameter (tsk).
Note that we can use group_search(cred->group_info, ...) as a
replacement for both in_group_p and in_egroup_p as these functions only
compare the parameter to cred->fsgid/egid and then call group_search.
In fact, the usage of in_group_p was even more incorrect: it compares to
cred->fsgid (which is usually equal to cred->egid) and not cred->gid.
GitHub issue:
https://github.com/linux-audit/audit-kernel/issues/82
Fixes: 37eebe39c973 ("audit: improve GID/EGID comparation logic")
Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com>
---
kernel/auditsc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ceb1c4596c51..518a3336a697 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -494,20 +494,20 @@ static int audit_filter_rules(struct task_struct *tsk,
result = audit_gid_comparator(cred->gid, f->op, f->gid);
if (f->op == Audit_equal) {
if (!result)
- result = in_group_p(f->gid);
+ result = groups_search(cred->group_info, f->gid);
} else if (f->op == Audit_not_equal) {
if (result)
- result = !in_group_p(f->gid);
+ result = !groups_search(cred->group_info, f->gid);
}
break;
case AUDIT_EGID:
result = audit_gid_comparator(cred->egid, f->op, f->gid);
if (f->op == Audit_equal) {
if (!result)
- result = in_egroup_p(f->gid);
+ result = groups_search(cred->group_info, f->gid);
} else if (f->op == Audit_not_equal) {
if (result)
- result = !in_egroup_p(f->gid);
+ result = !groups_search(cred->group_info, f->gid);
}
break;
case AUDIT_SGID:
--
2.17.1
6 years, 6 months
[RFC PATCH ghak88 V1] audit: tie ANOM_ABEND records to syscall
by Richard Guy Briggs
Since core dump events are triggered by user activity, tie the
ANOM_ABEND record to the syscall record to collect all records from the
same event.
See: https://github.com/linux-audit/audit-kernel/issues/88
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index fefb9e2..5f0bd5e 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2461,7 +2461,7 @@ void audit_core_dumps(long signr)
if (signr == SIGQUIT) /* don't care for those */
return;
- ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
+ ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_ANOM_ABEND);
if (unlikely(!ab))
return;
audit_log_task(ab);
--
1.8.3.1
6 years, 6 months
[RFC PATCH ghak87 V1] audit: tie SECCOMP records to syscall
by Richard Guy Briggs
Since seccomp events are triggered by user activity, tie the SECCOMP
record to the syscall record to collect all records from the same event.
See: https://github.com/linux-audit/audit-kernel/issues/87
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
kernel/auditsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index ceb1c45..fefb9e2 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2485,7 +2485,7 @@ void audit_seccomp(unsigned long syscall, long signr, int code)
{
struct audit_buffer *ab;
- ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_SECCOMP);
+ ab = audit_log_start(audit_context(), GFP_KERNEL, AUDIT_SECCOMP);
if (unlikely(!ab))
return;
audit_log_task(ab);
--
1.8.3.1
6 years, 6 months
[RFC PATCH 0/2] Extend AUDIT_EXE and AUDIT_DIR to more filter types
by Ondrej Mosnacek
This patch set extends the previous AUDIT_EXE patch by also doing a similar
thing with the AUDIT_DIR field.
I am sending it as RFC since this change requires passing audit_context to
audit_filter and I'm not sure if I should also pass it when doing the
AUDIT_FILTER_USER filtering. The call site does not have the ctx variable,
although I suppose it could be extracted from the current task somehow, but I'm
not sure if it even makes sense to use it in that place. I am not enabling
AUDIT_DIR for AUDIT_FILTER_USER in this patch, but if it makes sense I will do
that in the final patch.
Paul/Richard, please advise. See the FIXME in the second patch for the
problematic location.
Ondrej Mosnacek (2):
audit: allow other filter list types for AUDIT_EXE
[WIP] audit: allow other filter list types for AUDIT_DIR
kernel/audit.c | 5 +++--
kernel/audit.h | 32 +++++++++++++++++++++++++++++++-
kernel/audit_tree.c | 4 +++-
kernel/auditfilter.c | 13 ++++++++++---
kernel/auditsc.c | 28 ----------------------------
5 files changed, 47 insertions(+), 35 deletions(-)
--
2.17.0
6 years, 6 months
audit/next rebased to v4.18-rc1
by Paul Moore
A quick note to let you know that I've rebased audit/next on top of
v4.18-rc1, and now that merge window is closed I'm going to be working
my way through the patch backlog this week.
You may also notice that there is now a README.md in the audit/master
branch with some basic information and links (it's been there for a
week or two). Eventually I'm going to add administrative information,
e.g. the audit kernel process[1], to this file so we have it in a
central location, but if there is anything else you can think of that
should be in this file let me know.
[1] http://www.paul-moore.com/blog/d/2017/07/kernel_repo_process.html
--
paul moore
www.paul-moore.com
6 years, 6 months
Hung processes stuck in D state after starting a second audit consumer
by Preston Bennes
Greetings audit mailing list,
I've got an AWS instance running an Amazon Linux kernel,
4.9.77-31.58.amzn1.x86_64
with the base OS being CentOS 6. The instance had one program with the
audit handle (Proprietary closed source software, Lacework agent). I
installed and started OSQuery which attempted to acquire the audit handle.
I'm unsure if osquery was successful or not, because I was unable to ssh in
to the server to investigate. I ended up having to restart the instance.
Almost immediately after starting osquery, sshd got stuck in D state.
syslog has a hung task warning and backtrace that provides some information:
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.724101]
> INFO: task sshd:1840 blocked for more than 10 seconds.
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.727856]
> Tainted: G E 4.9.77-31.58.amzn1.x86_64 #1
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.731856]
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736283]
> sshd D 0 1840 1839 0x00000080
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736287]
> 0000000000000000 ffff8802025c6540 ffff88003684d940 ffff880205f3bb80
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736290]
> ffff8802072582c0 ffffc900049bfc60 ffffffff81556e62 0000000000000001
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736292]
> 004200ca00000001 ffff8802072582c0 0000000000000000 ffffffff81a65140
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736295] Call
> Trace:
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736302]
> [<ffffffff81556e62>] ? __schedule+0x242/0x700
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736304]
> [<ffffffff8155734c>] schedule+0x2c/0x80
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736306]
> [<ffffffff815575ee>] schedule_preempt_disabled+0xe/0x10
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736308]
> [<ffffffff81558f05>] __mutex_lock_slowpath+0x95/0x110
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736311]
> [<ffffffff8147a6f8>] ? __alloc_skb+0x78/0x1e0
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736313]
> [<ffffffff81558f97>] mutex_lock+0x17/0x30
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736316]
> [<ffffffff811178bd>] audit_receive+0x1d/0x90
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736319]
> [<ffffffff814c4976>] netlink_unicast+0x176/0x220
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736320]
> [<ffffffff814c4cf6>] netlink_sendmsg+0x2d6/0x390
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736323]
> [<ffffffff814719fe>] sock_sendmsg+0x3e/0x50
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736324]
> [<ffffffff81471ead>] SYSC_sendto+0x11d/0x150
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736327]
> [<ffffffff8111c68b>] ? __audit_syscall_entry+0xbb/0x100
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736330]
> [<ffffffff81003478>] ? syscall_trace_enter+0x1c8/0x2c0
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736332]
> [<ffffffff814728ee>] SyS_sendto+0xe/0x10
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736333]
> [<ffffffff81003b09>] do_syscall_64+0x59/0xc0
Jun 14 20:54:53 packer_default-10-180-21-138 kernel: [12191989.736335]
> [<ffffffff8155bd70>] entry_SYSCALL64_slow_path+0x25/0x25
I've been doing some reading (ex.
https://www.redhat.com/archives/linux-audit/2016-February/msg00025.html )
and my understanding is that osquery should have been able to acquire the
audit handle, trampling lacework's ("Last one wins"), but I don't have
access to the Lacework code to know how it might handle that situation (I'm
engaging their support separately). I also noticed the patch set for 4.17
seemed to include some changes around the code path in the backtrace. I'm
trying to understand this behavior and determine if it's a bug, if said bug
has already been fixed by a patch between 4.9.77 and 4.17, or that this
issue is a lack of my understanding of the behavior of the audit system. It
is surprising to me that an audit system related issue would result in sshd
getting stuck in D state. Several other processes on the system continued
running without incident. Processed launched out of cron also got stuck in
D state. I would be grateful for some expert insight. If this isn't a bug
and is a misunderstanding on my part, is there any way to configure the
audit system such that an issue won't result in processes getting stuck in
D state?
Thanks,
Preston Bennes
6 years, 6 months
audit trim and audit make_equiv
by Richard Guy Briggs
Hi Al,
I'm trying to trigger records for all the instances of
AUDIT_CONFIG_CHANGE, but I'm having trouble with a few.
AUDIT_TRIM ("auditctl -t": Trim the subtrees after a mount command.):
My reading is that should trigger at least one message (which it does)
and potentially more depending on existing tree watches and mounts via
audit_trim_trees(). I've not been able to trigger any additional ones.
What I've tried to do to trigger additional ones is to mount a
filesystem, create a subdirectory within it, set a watch on that
subdirectory, unmount the filesystem and then run a trim command. I've
also tried the other way around, which I didn't expect to work, creating
a subdirectory, set a watch on that subdirectory, mount a filesystem on
its parent, then run a trim command.
AUDIT_MAKE_EQUIV ("auditctl -q mount-point,subtree": Make subtree
equivalent under mount point.):
The way I read this code is it should trigger at least one message
(which it does) and potentially more depending on failures of
iterate_mounts() in audit_tag_tree(). I don't know how to trigger the
latter. Are you able to prescribe a recipe to do so?
Any insights? Thanks!
- 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
6 years, 6 months
auditd rule error
by Joshua Ammons
On a server running RHEL 7.2 the audit rules fail to load due to an error on this rule:
-a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=10.2.5.b-elevated-privs-session
>From what I have found it seems "exe" may not be a valid field on this specific O.S. - is this correct? Does anyone have any recommendations on how to track elevated privileges for all RHEL 6/7 systems?
6 years, 6 months
