Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <4df50e95-6173-4ed1-9d08-3c1c4abab23f@gmail.com>
 <CAHC9VhSjTqT-4TMxBnQOQHkj+djONihfeoPVyy1egrZY2t10XA@mail.gmail.com>
 <c8a616e4-26a6-af51-212c-31dca0e265cd@gmail.com> <CAHC9VhQTZdeNOx3AXdoc9LXUzDk5n7wyGBX-tV-ZaovhPAdWwQ@mail.gmail.com>
 <e85dd38b-ef7b-ed7e-882e-124cdf942c44@gmail.com>
In-Reply-To: <e85dd38b-ef7b-ed7e-882e-124cdf942c44@gmail.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Tue, 1 Feb 2022 12:26:05 -0500
Message-ID: <CAHC9VhROuJtvNHuVaR6pEekNFacH3Tywx58_hn1f5Mwk+kjC8g@mail.gmail.com>
Subject: Re: [PATCH] SELinux: Always allow FIOCLEX and FIONCLEX
To:     Demi Marie Obenour <demiobenour@gmail.com>
Cc:     Stephen Smalley <stephen.smalley.work@gmail.com>,
        Eric Paris <eparis@parisplace.org>, selinux@vger.kernel.org,
        linux-kernel@vger.kernel.org, selinux-refpolicy@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jan 29, 2022 at 10:40 PM Demi Marie Obenour
<demiobenour@gmail.com> wrote:
> On 1/26/22 17:41, Paul Moore wrote:
> > On Tue, Jan 25, 2022 at 5:50 PM Demi Marie Obenour
> > <demiobenour@gmail.com> wrote:
> >> On 1/25/22 17:27, Paul Moore wrote:
> >>> On Tue, Jan 25, 2022 at 4:34 PM Demi Marie Obenour
> >>> <demiobenour@gmail.com> wrote:
> >>>>
> >>>> These ioctls are equivalent to fcntl(fd, F_SETFD, flags), which SELinux
> >>>> always allows too.  Furthermore, a failed FIOCLEX could result in a file
> >>>> descriptor being leaked to a process that should not have access to it.
> >>>>
> >>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> >>>> ---
> >>>>  security/selinux/hooks.c | 5 +++++
> >>>>  1 file changed, 5 insertions(+)
> >>>
> >>> I'm not convinced that these two ioctls should be exempt from SELinux
> >>> policy control, can you explain why allowing these ioctls with the
> >>> file:ioctl permission is not sufficient for your use case?  Is it a
> >>> matter of granularity?
> >>
> >> FIOCLEX and FIONCLEX are applicable to *all* file descriptors, not just
> >> files.  If I want to allow them with SELinux policy, I have to grant
> >> *:ioctl to all processes and use xperm rules to determine what ioctls
> >> are actually allowed.  That is incompatible with existing policies and
> >> needs frequent maintenance when new ioctls are added.
> >>
> >> Furthermore, these ioctls do not allow one to do anything that cannot
> >> already be done by fcntl(F_SETFD), and (unless I have missed something)
> >> SELinux unconditionally allows that.  Therefore, blocking these ioctls
> >> does not improve security, but does risk breaking userspace programs.
> >> The risk is especially great because in the absence of SELinux, I
> >> believe FIOCLEX and FIONCLEX *will* always succeed, and userspace
> >> programs may rely on this.  Worse, if a failure of FIOCLEX is ignored,
> >> a file descriptor can be leaked to a child process that should not have
> >> access to it, but which SELinux allows access to.  Userspace
> >> SELinux-naive sandboxes are one way this could happen.  Therefore,
> >> blocking FIOCLEX may *create* a security issue, and it cannot solve one.
> >
> > I can see you are frustrated with my initial take on this, but please
> > understand that excluding an operation from the security policy is not
> > something to take lightly and needs discussion.  I've added the
> > SELinux refpolicy list to this thread as I believe their input would
> > be helpful here.
>
> Absolutely it is not something that should be taken lightly, though I
> strongly believe it is correct in this case.  Is one of my assumptions
> mistaken?

My concern is that there is a distro/admin somewhere which is relying
on their SELinux policy enforcing access controls on these ioctls and
removing these controls would cause them a regression.

-- 
paul-moore.com