public inbox for [email protected]
 help / color / mirror / Atom feed
From: Paul Moore <[email protected]>
To: [email protected], [email protected],
	[email protected], [email protected],
	[email protected],
	Kumar Kartikeya Dwivedi <[email protected]>,
	Jens Axboe <[email protected]>,
	Pavel Begunkov <[email protected]>
Subject: [RFC PATCH v2 0/9] Add LSM access controls and auditing to io_uring
Date: Wed, 11 Aug 2021 16:48:11 -0400	[thread overview]
Message-ID: <162871480969.63873.9434591871437326374.stgit@olly> (raw)

Draft #2 of the patchset which brings auditing and proper LSM access
controls to the io_uring subsystem.  The original patchset was posted
in late May and can be found via lore using the link below:

https://lore.kernel.org/linux-security-module/162163367115.8379.8459012634106035341.stgit@sifl/

This draft should incorporate all of the feedback from the original
posting as well as a few smaller things I noticed while playing
further with the code.  The big change is of course the selective
auditing in the io_uring op servicing, but that has already been
discussed quite a bit in the original thread so I won't go into
detail here; the important part is that we found a way to move
forward and this draft captures that.  For those of you looking to
play with these patches, they are based on Linus' v5.14-rc5 tag and
on my test system they boot and appear to function without problem;
they pass the selinux-testsuite and audit-testsuite and I have not
noticed any regressions in the normal use of the system.  If you want
to get a copy of these patches straight from git you can use the
"working-io_uring" branch in the repo below:

git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git

Beyond the existing test suite tests mentioned above, I've cobbled
together some very basic, very crude tests to exercise some of the
things I care about from a LSM/audit perspective.  These tests are
pretty awful (I'm not kidding), but they might be helpful for the
other LSM/audit developers who want to test things:

https://drop.paul-moore.com/90.kUgq

There are currently two tests: 'iouring.2' and 'iouring.3';
'iouring.1' was lost in a misguided and overzealous 'rm' command.
The first test is standalone and basically tests the SQPOLL
functionality while the second tests sharing io_urings across process
boundaries and the credential/personality sharing mechanism.  The
console output of both tests isn't particularly useful, the more
interesting bits are in the audit and LSM specific logs.  The
'iouring.2' command requires no special arguments to run but the
'iouring.3' test is split into a "server" and "client"; the server
should be run without argument:

  % ./iouring.3s
  >>> server started, pid = 11678
  >>> memfd created, fd = 3
  >>> io_uring created; fd = 5, creds = 1

... while the client should be run with two arguments: the first is
the PID of the server process, the second is the "memfd" fd number:

  % ./iouring.3c 11678 3
  >>> client started, server_pid = 11678 server_memfd = 3
  >>> io_urings = 5 (server) / 5 (client)
  >>> io_uring ops using creds = 1
  >>> async op result: 36
  >>> async op result: 36
  >>> async op result: 36
  >>> async op result: 36
  >>> START file contents
  What is this life if, full of care,
  we have no time to stand and stare.
  >>> END file contents

The tests were hacked together from various sources online,
attribution and links to additional info can be found in the test
sources, but I expect these tests to die a fiery death in the not
to distant future as I work to add some proper tests to the SELinux
and audit test suites.

As I believe these patches should spend a full -rcX cycle in
linux-next, my current plan is to continue to solicit feedback on
these patches while they undergo additional testing (next up is
verification of the audit filter code for io_uring).  Assuming no
critical issues are found on the mailing lists or during testing, I
will post a proper patchset later with the idea of merging it into
selinux/next after the upcoming merge window closes.

Any comments, feedback, etc. are welcome.

---

Casey Schaufler (1):
      Smack: Brutalist io_uring support with debug

Paul Moore (8):
      audit: prepare audit_context for use in calling contexts beyond
             syscalls
      audit,io_uring,io-wq: add some basic audit support to io_uring
      audit: dev/test patch to force io_uring auditing
      audit: add filtering for io_uring records
      fs: add anon_inode_getfile_secure() similar to
          anon_inode_getfd_secure()
      io_uring: convert io_uring to the secure anon inode interface
      lsm,io_uring: add LSM hooks to io_uring
      selinux: add support for the io_uring access controls


 fs/anon_inodes.c                    |  29 ++
 fs/io-wq.c                          |   4 +
 fs/io_uring.c                       |  69 +++-
 include/linux/anon_inodes.h         |   4 +
 include/linux/audit.h               |  26 ++
 include/linux/lsm_hook_defs.h       |   5 +
 include/linux/lsm_hooks.h           |  13 +
 include/linux/security.h            |  16 +
 include/uapi/linux/audit.h          |   4 +-
 kernel/audit.h                      |   7 +-
 kernel/audit_tree.c                 |   3 +-
 kernel/audit_watch.c                |   3 +-
 kernel/auditfilter.c                |  15 +-
 kernel/auditsc.c                    | 483 +++++++++++++++++++-----
 security/security.c                 |  12 +
 security/selinux/hooks.c            |  34 ++
 security/selinux/include/classmap.h |   2 +
 security/smack/smack_lsm.c          |  64 ++++
 18 files changed, 678 insertions(+), 115 deletions(-)

             reply	other threads:[~2021-08-11 20:48 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-11 20:48 Paul Moore [this message]
2021-08-11 20:48 ` [RFC PATCH v2 1/9] audit: prepare audit_context for use in calling contexts beyond syscalls Paul Moore
2021-08-11 20:48 ` [RFC PATCH v2 2/9] audit,io_uring,io-wq: add some basic audit support to io_uring Paul Moore
2021-08-11 20:48 ` [RFC PATCH v2 3/9] audit: dev/test patch to force io_uring auditing Paul Moore
2021-08-11 20:48 ` [RFC PATCH v2 4/9] audit: add filtering for io_uring records Paul Moore
2021-08-11 20:48 ` [RFC PATCH v2 5/9] fs: add anon_inode_getfile_secure() similar to anon_inode_getfd_secure() Paul Moore
2021-08-12  9:32   ` Mickaël Salaün
2021-08-12 14:32     ` Paul Moore
2021-08-12 15:35       ` Mickaël Salaün
2021-08-11 20:48 ` [RFC PATCH v2 6/9] io_uring: convert io_uring to the secure anon inode interface Paul Moore
2021-08-11 20:48 ` [RFC PATCH v2 7/9] lsm,io_uring: add LSM hooks to io_uring Paul Moore
2021-08-11 20:49 ` [RFC PATCH v2 8/9] selinux: add support for the io_uring access controls Paul Moore
2021-08-11 20:49 ` [RFC PATCH v2 9/9] Smack: Brutalist io_uring support with debug Paul Moore
2021-08-31 14:44   ` Paul Moore
2021-08-31 15:03     ` Casey Schaufler
2021-08-31 16:43       ` Paul Moore
2021-08-24 20:57 ` [RFC PATCH v2 0/9] Add LSM access controls and auditing to io_uring Richard Guy Briggs
2021-08-24 22:27   ` Paul Moore
2021-08-25  1:36     ` Richard Guy Briggs
2021-08-26  1:16   ` Richard Guy Briggs
2021-08-26  1:34     ` Paul Moore
2021-08-26 16:32       ` Richard Guy Briggs
2021-08-26 19:14         ` Paul Moore
2021-08-27 13:35           ` Richard Guy Briggs
2021-08-27 19:49             ` Paul Moore
2021-08-28 15:03               ` Richard Guy Briggs
2021-08-29 15:18                 ` Paul Moore
2021-09-01 19:21                   ` Paul Moore
2021-09-10  0:58                     ` Richard Guy Briggs
2021-09-13 19:23                       ` Paul Moore
2021-09-14  1:50                         ` Paul Moore
2021-09-14  2:49                           ` Paul Moore
2021-09-15 12:29                             ` Richard Guy Briggs
2021-09-15 13:02                               ` Steve Grubb
2021-09-15 14:12                               ` Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=162871480969.63873.9434591871437326374.stgit@olly \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox