How to confirm AUDITD is immutable
by warron.french
Hello, I just wanted to confirm for my memory that if I wanted to confirm
that the auditd process running on my system was configured correctly and
intended to be
*immutable (*setting *-e 2*) I would do so easily by executing:
*auditctl -s*
When I execute that command I get back in the results that have:
*enabled 1*
*loginuid_immutable 0 unlocked*
*among a few other lines.*
Shouldn't I actually see *enabled 2*?
I have in one of our .rules files under /etc/audit/rules.d/ the syntax
"-e 2".
Thanks,
--------------------------
Warron French
4 years, 2 months
[GIT PULL] Audit patches for v5.10
by Paul Moore
Hi Linus,
A small set of audit patches for v5.10. There are only three patches
in total, and all three are trivial fixes that don't really warrant
any explanations beyond their descriptions. As usual, all three
patches pass our test suite and as of a few minutes ago they applied
cleanly to your tree. Please merge for v5.10.
Thanks,
-Paul
--
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
stable-5.10
for you to fetch changes up to c07203516439b9cd9f7b3cbed82a77164de5af40:
audit: Remove redundant null check (2020-08-26 09:10:39 -0400)
----------------------------------------------------------------
Jules Irenge (2):
audit: change unnecessary globals into statics
audit: uninitialize variable audit_sig_sid
Xu Wang (1):
audit: Remove redundant null check
kernel/audit.c | 9 ++++-----
kernel/audit.h | 4 ----
2 files changed, 4 insertions(+), 9 deletions(-)
--
paul moore
www.paul-moore.com
4 years, 2 months
auditing signals
by Richard Guy Briggs
Hello auditors and auditees...
Have you got any rules or tests to test audit logging signals or ptrace?
I thought I understood how it worked, but it appears I need to signal a task group.
I was a little less sure of how to trigger a ptrace audit log, but also figured that out.
I wrote up an audit-testsuite test case to test it and it made two seperate sys_kill calls which generated two events rather than the one I was looking for to fill the aux_pids structure.
https://github.com/linux-audit/audit-testsuite/compare/master...rgbriggs:...
It is essentially:
sleep 5& t1=$!
sleep 5& t2=$!
auditctl -a always,exit -F arch=b64 -S kill -F key=testkill
kill -TERM $t1 $t2
sleep 1
auditctl -d always,exit -F arch=b64 -S kill -F key=testkill
sleep 2 # let the queue drain
ausearch -ts recent -i -k testkill
The output looks something like this when I was hoping for one event with two OBJ_PID records.
type=PROCTITLE msg=audit(04/08/2019 06:58:12.308:277) : proctitle=bash -l
type=OBJ_PID msg=audit(04/08/2019 06:58:12.308:277) : opid=6104 oauid=root ouid=root oses=3 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=sleep
type=SYSCALL msg=audit(04/08/2019 06:58:12.308:277) : arch=x86_64 syscall=kill success=yes exit=0 a0=0x17d8 a1=SIGTERM a2=0x0 a3=0x7f119b4919c0 items=0 ppid=6066 pid=6083 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=testkill
----
type=PROCTITLE msg=audit(04/08/2019 06:58:12.308:278) : proctitle=bash -l
type=OBJ_PID msg=audit(04/08/2019 06:58:12.308:278) : opid=6105 oauid=root ouid=root oses=3 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=sleep
type=SYSCALL msg=audit(04/08/2019 06:58:12.308:278) : arch=x86_64 syscall=kill success=yes exit=0 a0=0x17d9 a1=SIGTERM a2=0x0 a3=0x7f119b4919c0 items=0 ppid=6066 pid=6083 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 ses=3 comm=bash exe=/usr/bin/bash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=testkill
Now the trick is how to trigger more than one OBJ_PID record in a single syscall, which was the original goal of the exercise. It looks like it might need to be a signal sent to a process group with more than one task or a task that has threaded.
Can anyone suggest a simple test preferrably using our audit-testsuite perl infrasructure to get more than one OBJ_PID record?
The code in question was introduced:
c2f0c7c356dc <sgrubb(a)redhat.com> 2005-05-06 audit_signal_info AUDIT_TERM_INFO (single pid)
e54dc2431d74 <amy.griffis(a)hp.com> 2007-03-29 ("[PATCH] audit signal recipients") (multi-pid)
When auditing syscalls that send signals, log the pid and security context for each target process.
Optimize the data collection by adding a counter for signal-related rules, and avoiding allocating an aux struct unless we have more than one target process.
For process groups, collect pid/context data in blocks of 16.
Move the audit_signal_info() hook up in check_kill_permission() so we audit attempts where permission is denied.
a5cb013da773 <viro(a)zeniv.linux.org.uk> 2007-03-20 ("[PATCH] auditing ptrace")
As a bit of an aside, it occurs to me that there could be information overwritten if signal information was stored before ptrace information stored since ptrace uses the context->target_* slot directly whereas signals check to see if that slot is used first and then overflows to the context->aux_pids structure. If the ptrace information is always guaranteed to come first or alone, there is no issue.
If you are still reading this far, the interest in this arose from trying to find a way to connect potentially multiple OBJ_PID records with different CONTAINER_ID records in the ghak90 Audit Container ID patchset rather than using the op= field.
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
4 years, 2 months
[PATCH 2/3] fanotify: define bit map fields to hold response decision context
by Steve Grubb
This patch defines 2 bit maps within the response variable returned from
user space on a permission event. The first field is 3 bits for the context
type. The context type will describe what the meaning is of the second bit
field. The default is none. The patch defines one additional context type
which means that the second field is a rule number. This will allow for the
creation of 6 other context types in the future if other users of the API
identify different needs. The second field is 10 bits wide and can be used
to pass along the data described by the context. Neither of these bit maps
are directly adjacent and could be expanded if the need arises.
To support this, several macros were created to facilitate storing and
retrieving the values. There is also a macro for user space to check that
the data being sent is valid. Of course, without this check, anything that
overflows the bit field will trigger an EINVAL based on the use of
of INVALID_RESPONSE_MASK in process_access_response().
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
---
fs/notify/fanotify/fanotify.c | 3 +--
fs/notify/fanotify/fanotify_user.c | 7 +------
include/linux/fanotify.h | 5 +++++
include/uapi/linux/fanotify.h | 31 ++++++++++++++++++++++++++++++
4 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 85eda539b35f..e72b7e59aa24 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -178,11 +178,10 @@ static int fanotify_get_response(struct fsnotify_group *group,
}
/* userspace responded, convert to something usable */
- switch (event->response & ~FAN_AUDIT) {
+ switch (FAN_DEC_MASK(event->response)) {
case FAN_ALLOW:
ret = 0;
break;
- case FAN_DENY:
default:
ret = -EPERM;
}
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index c8da9ea1e76e..3b8e515904fc 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -187,13 +187,8 @@ static int process_access_response(struct fsnotify_group *group,
* userspace can send a valid response or we will clean it up after the
* timeout
*/
- switch (response & ~FAN_AUDIT) {
- case FAN_ALLOW:
- case FAN_DENY:
- break;
- default:
+ if (FAN_INVALID_RESPONSE_MASK(response))
return -EINVAL;
- }
if (fd < 0)
return -EINVAL;
diff --git a/include/linux/fanotify.h b/include/linux/fanotify.h
index b79fa9bb7359..b3281d0e1b55 100644
--- a/include/linux/fanotify.h
+++ b/include/linux/fanotify.h
@@ -72,6 +72,11 @@
#define ALL_FANOTIFY_EVENT_BITS (FANOTIFY_OUTGOING_EVENTS | \
FANOTIFY_EVENT_FLAGS)
+/* This mask is to check for invalid bits of a user space permission response */
+#define FAN_INVALID_RESPONSE_MASK(x) ((x) & ~(FAN_ALLOW | FAN_DENY | \
+ FAN_AUDIT | FAN_DEC_CONTEXT_TYPE | \
+ FAN_DEC_CONTEXT))
+
/* Do not use these old uapi constants internally */
#undef FAN_ALL_CLASS_BITS
#undef FAN_ALL_INIT_FLAGS
diff --git a/include/uapi/linux/fanotify.h b/include/uapi/linux/fanotify.h
index a88c7c6d0692..785d68ebcb58 100644
--- a/include/uapi/linux/fanotify.h
+++ b/include/uapi/linux/fanotify.h
@@ -152,6 +152,37 @@ struct fanotify_response {
#define FAN_DENY 0x02
#define FAN_AUDIT 0x10 /* Bit mask to create audit record for result */
+/*
+ * User space may need to record additional information about its decision.
+ * The context type records what kind of information is included. A bit mask
+ * defines the type of information included and then the context of the
+ * decision. The context type is 3 bits allowing for 8 kinds of context.
+ * The default is none. We also define 10 bits to allow up to 1024 kinds of
+ * context to be returned.
+ *
+ * If the context type is Rule, then the context following is the rule number
+ * that triggered the user space decision.
+ *
+ * There are helper macros defined so that it can be standardized across tools.
+ * A full example of how user space can use this looks like this:
+ *
+ * if (FAN_DEC_CONTEXT_VALUE_VALID(rule_number))
+ * response.response = FAN_DENY | FAN_AUDIT | FAN_DEC_CONTEXT_TYPE_RULE |
+ * FAN_DEC_CONTEXT_VALUE(rule_number);
+ */
+#define FAN_DEC_MASK(x) ((x) & (FAN_ALLOW|FAN_DENY))
+#define FAN_DEC_CONTEXT_TYPE 0x70000000
+#define FAN_DEC_CONTEXT 0x00FFC000
+
+#define FAN_DEC_CONTEXT_TYPE_VALUE(x) (((x) & 0x07) << 28)
+#define FAN_DEC_CONTEXT_TYPE_TO_VALUE(x) (((x) & FAN_DEC_CONTEXT_TYPE) >> 28)
+#define FAN_DEC_CONTEXT_VALUE(x) (((x) & 0x3FF) << 14)
+#define FAN_DEC_CONTEXT_TO_VALUE(x) (((x) & FAN_DEC_CONTEXT) >> 14)
+#define FAN_DEC_CONTEXT_VALUE_VALID(x) ((x) >= 0 && (x) < 1024)
+
+#define FAN_DEC_CONTEXT_TYPE_NONE FAN_DEC_CONTEXT_TYPE_VALUE(0)
+#define FAN_DEC_CONTEXT_TYPE_RULE FAN_DEC_CONTEXT_TYPE_VALUE(1)
+
/* No fd set in event */
#define FAN_NOFD -1
--
2.26.2
4 years, 2 months
[PATCH 1/3] fanotify: Ensure consistent variable type for response
by Steve Grubb
The user space API for the response variable is __u32. This patch makes
sure that the whole path through the kernel uses __u32 so that there is
no sign extension or truncation of the user space response.
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
---
fs/notify/fanotify/fanotify.h | 2 +-
fs/notify/fanotify/fanotify_user.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/notify/fanotify/fanotify.h b/fs/notify/fanotify/fanotify.h
index 8ce7ccfc4b0d..c397993830ac 100644
--- a/fs/notify/fanotify/fanotify.h
+++ b/fs/notify/fanotify/fanotify.h
@@ -165,7 +165,7 @@ FANOTIFY_PE(struct fanotify_event *event)
struct fanotify_perm_event {
struct fanotify_event fae;
struct path path;
- unsigned short response; /* userspace answer to the event */
+ __u32 response; /* userspace answer to the event */
unsigned short state; /* state of the event */
int fd; /* fd we passed to userspace for this event */
};
diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index 63b5dffdca9e..c8da9ea1e76e 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -157,7 +157,7 @@ static int create_fd(struct fsnotify_group *group, struct path *path,
*/
static void finish_permission_event(struct fsnotify_group *group,
struct fanotify_perm_event *event,
- unsigned int response)
+ __u32 response)
__releases(&group->notification_lock)
{
bool destroy = false;
@@ -178,7 +178,7 @@ static int process_access_response(struct fsnotify_group *group,
{
struct fanotify_perm_event *event;
int fd = response_struct->fd;
- int response = response_struct->response;
+ __u32 response = response_struct->response;
pr_debug("%s: group=%p fd=%d response=%d\n", __func__, group,
fd, response);
--
2.26.2
4 years, 2 months
