Thread (67 messages) 67 messages, 10 authors, 2021-08-25

Re: [RFC PATCH 2/9] audit, io_uring, io-wq: add some basic audit support to io_uring

From: Paul Moore <paul@paul-moore.com>
Date: 2021-08-25 19:41:39
Also in: linux-fsdevel, linux-security-module, selinux

On Tue, Aug 24, 2021 at 9:21 PM Richard Guy Briggs [off-list ref] wrote:
On 2021-06-02 13:46, Paul Moore wrote:
quoted
On Wed, Jun 2, 2021 at 1:29 PM Richard Guy Briggs [off-list ref] wrote:
quoted
On 2021-05-21 17:49, Paul Moore wrote:
quoted
WARNING - This is a work in progress and should not be merged
anywhere important.  It is almost surely not complete, and while it
probably compiles it likely hasn't been booted and will do terrible
things.  You have been warned.

This patch adds basic auditing to io_uring operations, regardless of
their context.  This is accomplished by allocating audit_context
structures for the io-wq worker and io_uring SQPOLL kernel threads
as well as explicitly auditing the io_uring operations in
io_issue_sqe().  The io_uring operations are audited using a new
AUDIT_URINGOP record, an example is shown below:

  % <TODO - insert AUDIT_URINGOP record example>

Thanks to Richard Guy Briggs for review and feedback.

Signed-off-by: Paul Moore <paul@paul-moore.com>
---
 fs/io-wq.c                 |    4 +
 fs/io_uring.c              |   11 +++
 include/linux/audit.h      |   17 ++++
 include/uapi/linux/audit.h |    1
 kernel/audit.h             |    2 +
 kernel/auditsc.c           |  173 ++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 208 insertions(+)
...
quoted
quoted
quoted
+     if (ctx->return_valid != AUDITSC_INVALID)
+             audit_log_format(ab, " success=%s exit=%ld",
+                              (ctx->return_valid == AUDITSC_SUCCESS ?
+                               "yes" : "no"),
+                              ctx->return_code);
+     audit_log_format(ab,
+                      " items=%d"
+                      " ppid=%d pid=%d auid=%u uid=%u gid=%u"
+                      " euid=%u suid=%u fsuid=%u"
+                      " egid=%u sgid=%u fsgid=%u",
+                      ctx->name_count,
+                      task_ppid_nr(current),
+                      task_tgid_nr(current),
+                      from_kuid(&init_user_ns, audit_get_loginuid(current)),
+                      from_kuid(&init_user_ns, cred->uid),
+                      from_kgid(&init_user_ns, cred->gid),
+                      from_kuid(&init_user_ns, cred->euid),
+                      from_kuid(&init_user_ns, cred->suid),
+                      from_kuid(&init_user_ns, cred->fsuid),
+                      from_kgid(&init_user_ns, cred->egid),
+                      from_kgid(&init_user_ns, cred->sgid),
+                      from_kgid(&init_user_ns, cred->fsgid));
The audit session ID is still important, relevant and qualifies auid.
In keeping with the SYSCALL record format, I think we want to keep
ses=audit_get_sessionid(current) in here.
This might be another case of syscall/io_uring confusion.  An io_uring
op doesn't necessarily have an audit session ID or an audit UID in the
conventional sense; for example think about SQPOLL works, shared
rings, etc.
Right, but those syscalls are what instigate io_uring operations, so
whatever process starts that operation, or gets handed that handle
should be tracked with auid and sessionid (the two work together to
track) unless we can easily track io_uring ops to connect them to a
previous setup syscall.  If we see a need to keep the auid, then the
sessionid goes with it.
As a reminder, once the io_uring is created appropriately one can
issue io_uring operations without making a syscall.  Further, sharing
a io_uring across process boundaries means that both the audit session
ID and audit login UID used to create the io_uring might not be the
same as the subject which issues operations to the io_uring.

Any io_uring operations that happen synchronously as the result of a
syscall should be associated with the SYSCALL record so the session ID
and login UID will be part of the event.  Asynchronous operations will
not have that information because we don't have a way to get it.

-- 
paul moore
www.paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help