All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Alfred Piccioni <alpic@google.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	stable@vger.kernel.org,  selinux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] SELinux: Introduce security_file_ioctl_compat hook
Date: Mon, 18 Dec 2023 08:50:10 -0500	[thread overview]
Message-ID: <CAEjxPJ5mpMbTpnP1tbrFs9o2F0ymtaRbBPMMT4xogRmKbtZ2AA@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ6G7gHi=kLmgT3m1kDQeTpT1xLexDXbZRBMjJdiWrx=mw@mail.gmail.com>

On Mon, Dec 18, 2023 at 8:46 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Mon, Dec 18, 2023 at 7:43 AM Alfred Piccioni <alpic@google.com> wrote:
> >
> > Some ioctl commands do not require ioctl permission, but are routed to
> > other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is
> > done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*).
> >
> > However, if a 32-bit process is running on a 64-bit kernel, it emmits
>
> s/emmits/emits/
>
> > 32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are
> > being checked erroneously, which leads to these ioctl operations being
> > routed to the ioctl permission, rather than the correct file
> > permissions.
> >
> > This was also noted in a RED-PEN finding from a while back -
> > "/* RED-PEN how should LSM module know it's handling 32bit? */".
> >
> > This patch introduces a new hook, security_file_ioctl_compat, that
> > replaces security_file_ioctl if the CONFIG_COMPAT flag is on. All
> > current LSMs have been changed to hook into the compat flag.
>
> It doesn't (or shouldn't) replace security_file_ioctl, and the hook
> doesn't appear to be conditional on CONFIG_COMPAT per se.
> It is a new hook that is called from the compat ioctl syscall. The old
> hook continues to be used from the regular ioctl syscall and
> elsewhere.
>
> > Reviewing the three places where we are currently using
> > security_file_ioctl, it appears that only SELinux needs a dedicated
> > compat change; TOMOYO and SMACK appear to be functional without any
> > change.
> >
> > Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"")
> > Signed-off-by: Alfred Piccioni <alpic@google.com>
> > Cc: stable@vger.kernel.org
> > ---
> > diff --git a/fs/overlayfs/inode.c b/fs/overlayfs/inode.c
> > index 83ef66644c21..170687b5985b 100644
> > --- a/fs/overlayfs/inode.c
> > +++ b/fs/overlayfs/inode.c
> > @@ -751,7 +751,11 @@ static int ovl_security_fileattr(const struct path *realpath, struct fileattr *f
> >         else
> >                 cmd = fa->fsx_valid ? FS_IOC_FSGETXATTR : FS_IOC_GETFLAGS;
> >
> > +#ifdef CONFIG_COMPAT
> > +       err = security_file_ioctl_compat(file, cmd, 0);
> > +# else
> >         err = security_file_ioctl(file, cmd, 0);
> > +#endif
>
> I don't understand why you made this change, possibly a leftover of an
> earlier version of the patch that tried to replace
> security_file_ioctl() everywhere?

By the way, for extra credit, you could augment the ioctl tests in the
selinux-testsuite to also exercise this new hook and confirm that it
works correctly. See
https://github.com/SELinuxProject/selinux-testsuite particularly
tests/ioctl and policy/test_ioctl.te. Feel free to ask for help on
that.

  reply	other threads:[~2023-12-18 13:50 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-06 10:25 [PATCH] SELinux: Check correct permissions for FS_IOC32_* Alfred Piccioni
2023-09-06 10:28 ` kernel test robot
2023-09-06 11:59 ` [PATCH V2] " Alfred Piccioni
2023-09-06 17:49   ` Stephen Smalley
2023-09-08 22:54   ` kernel test robot
2023-09-11 13:19     ` Stephen Smalley
2023-09-11 13:49       ` Stephen Smalley
2023-09-12  9:00         ` Alfred Piccioni
2023-09-12 12:00           ` Stephen Smalley
2023-09-12 15:46             ` Mickaël Salaün
2023-09-13  3:52       ` Paul Moore
2023-12-18 12:41 ` [PATCH] SELinux: Introduce security_file_ioctl_compat hook Alfred Piccioni
2023-12-18 13:46   ` Stephen Smalley
2023-12-18 13:50     ` Stephen Smalley [this message]
2023-12-19  9:09 ` [PATCH] security: new security_file_ioctl_compat() hook Alfred Piccioni
2023-12-19  9:10   ` Alfred Piccioni
2023-12-20 14:38     ` Alfred Piccioni
2023-12-20 15:34     ` Stephen Smalley
2023-12-23 11:15     ` Fwd: " Tetsuo Handa
2023-12-23 14:41     ` Tetsuo Handa
2023-12-20 17:31   ` Stephen Smalley
2023-12-20 18:48   ` Eric Biggers
2023-12-23  1:23   ` Paul Moore
2023-12-23 10:48     ` Tetsuo Handa
2023-12-24 19:58       ` Paul Moore
2023-12-23 15:34     ` Eric Biggers
2023-12-24 20:00       ` Paul Moore
2023-12-24 20:09         ` Paul Moore
2023-12-23 17:54     ` Casey Schaufler
2023-12-24 20:53   ` Paul Moore
2023-12-27  4:43     ` Eric Biggers
2023-12-18 14:16 [PATCH] SELinux: Introduce security_file_ioctl_compat hook Alfred Piccioni
2023-12-18 14:22 ` Alfred Piccioni
2023-12-18 15:58 ` Stephen Smalley
2023-12-18 16:03   ` Stephen Smalley
2023-12-18 17:11 ` Casey Schaufler
2023-12-18 17:36   ` Stephen Smalley
2023-12-18 17:54     ` Casey Schaufler

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=CAEjxPJ5mpMbTpnP1tbrFs9o2F0ymtaRbBPMMT4xogRmKbtZ2AA@mail.gmail.com \
    --to=stephen.smalley.work@gmail.com \
    --cc=alpic@google.com \
    --cc=eparis@parisplace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.