mbox series

[GIT,PULL] SELinux patches for v5.12

Message ID CAHC9VhRkn65jgVW5fTRWOrDe+dXQD-_-BTN+rZ8Kcq5qxFi45Q@mail.gmail.com (mailing list archive)
State New
Headers show
Series [GIT,PULL] SELinux patches for v5.12 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20210215

Message

Paul Moore Feb. 15, 2021, 9:57 p.m. UTC
Hi Linus,

We've got a good handful of patches for SELinux this time around; with
everything passing the selinux-testsuite and applying cleanly to your
tree as of a few minutes ago.  The highlights are below:

- Add support for labeling anonymous inodes, and extend this new
support to userfaultfd.

- Fallback to SELinux genfs file labeling if the filesystem does not
have xattr support.  This is useful for virtiofs which can vary in its
xattr support depending on the backing filesystem.

- Classify and handle MPTCP the same as TCP in SELinux.

- Ensure consistent behavior between inode_getxattr and
inode_listsecurity when the SELinux policy is not loaded.  This fixes
a known problem with overlayfs.

- A couple of patches to prune some unused variables from the SELinux
code, mark private variables as static, and mark other variables as
__ro_after_init or __read_mostly.

Thanks,
-Paul

--
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:

 Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)

are available in the Git repository at:

 git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
   tags/selinux-pr-20210215

for you to fetch changes up to 365982aba1f264dba26f0908700d62bfa046918c:

 fs: anon_inodes: rephrase to appropriate kernel-doc
   (2021-01-15 12:17:25 -0500)

----------------------------------------------------------------
selinux/stable-5.12 PR 20210215

----------------------------------------------------------------
Amir Goldstein (1):
     selinux: fix inconsistency between inode_getxattr and inode_listsecurity

Daniel Colascione (3):
     fs: add LSM-supporting anon-inode interface
     selinux: teach SELinux about anonymous inodes
     userfaultfd: use secure anon inodes for userfaultfd

Lokesh Gidra (1):
     security: add inode_init_security_anon() LSM hook

Lukas Bulwahn (1):
     fs: anon_inodes: rephrase to appropriate kernel-doc

Ondrej Mosnacek (6):
     selinux: remove unused global variables
     selinux: drop the unnecessary aurule_callback variable
     selinux: make selinuxfs_mount static
     selinux: mark some global variables __ro_after_init
     selinux: mark selinux_xfrm_refcount as __read_mostly
     selinux: fall back to SECURITY_FS_USE_GENFS if no xattr support

Paolo Abeni (1):
     selinux: handle MPTCP consistently with TCP

fs/anon_inodes.c                    | 157 +++++++++++++++++++++++++--------
fs/libfs.c                          |   5 --
fs/userfaultfd.c                    |  19 ++---
include/linux/anon_inodes.h         |   5 ++
include/linux/lsm_hook_defs.h       |   2 +
include/linux/lsm_hooks.h           |   9 +++
include/linux/security.h            |  10 +++
security/security.c                 |   8 ++
security/selinux/avc.c              |  10 +--
security/selinux/hooks.c            | 141 ++++++++++++++++++++++++-----
security/selinux/ibpkey.c           |   1 -
security/selinux/include/classmap.h |   2 +
security/selinux/include/security.h |   1 -
security/selinux/netif.c            |   1 -
security/selinux/netlink.c          |   2 +-
security/selinux/netnode.c          |   1 -
security/selinux/netport.c          |   1 -
security/selinux/selinuxfs.c        |   4 +-
security/selinux/ss/avtab.c         |   4 +-
security/selinux/ss/ebitmap.c       |   2 +-
security/selinux/ss/hashtab.c       |   2 +-
security/selinux/ss/services.c      |  10 +--
security/selinux/xfrm.c             |   2 +-
23 files changed, 294 insertions(+), 105 deletions(-)

Comments

Linus Torvalds Feb. 22, 2021, 1:07 a.m. UTC | #1
On Mon, Feb 15, 2021 at 1:57 PM Paul Moore <paul@paul-moore.com> wrote:
>
> - Add support for labeling anonymous inodes, and extend this new
> support to userfaultfd.

I've pulled this, but I just have to note how much I hate the function
names. "secure inode"? There's nothing particularly secure about the
resulting inode.

It's gone through the security layer init, that doesn't make it
"secure". ALL normal inodes go through it, are all those inodes thus
"secure"? No.

Naming matters, and I think these things are actively mis-named
implying things that they aren't.

              Linus
pr-tracker-bot@kernel.org Feb. 22, 2021, 1:20 a.m. UTC | #2
The pull request you sent on Mon, 15 Feb 2021 16:57:38 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20210215

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d1fec2214bfbba5c759eb154b3744edb8c460384

Thank you!
Paul Moore Feb. 22, 2021, 10:57 p.m. UTC | #3
On Sun, Feb 21, 2021 at 8:07 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Feb 15, 2021 at 1:57 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > - Add support for labeling anonymous inodes, and extend this new
> > support to userfaultfd.
>
> I've pulled this, but I just have to note how much I hate the function
> names. "secure inode"? There's nothing particularly secure about the
> resulting inode.
>
> It's gone through the security layer init, that doesn't make it
> "secure". ALL normal inodes go through it, are all those inodes thus
> "secure"? No.
>
> Naming matters, and I think these things are actively mis-named
> implying things that they aren't.

I don't disagree that naming is important, I would only add,
non-sarcastically, that naming is hard (as a coworker likes to remind
me on a regular basis).

My personal take on the "secure" function variant is that it provides
some indication that this is tied to a LSM hook.  For better or worse,
all of the LSM hooks start off with "security_" and most (all?) of the
LSM blob void pointers in various structs throughout the kernel are
named "security".  While arguments can be made about the merits of
that depending on how you define "security", the fact remains that
they are named that way.  If you, or anyone else reading this, has
another suggestion for the function names I'm listening ...