linux-kernel - Re: [PATCH] SELinux: Always allow FIOCLEX and FIONCLEX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c8a616e4-26a6-af51-212c-31dca0e265cd@gmail.com>
Date:   Tue, 25 Jan 2022 17:50:14 -0500
From:   Demi Marie Obenour <demiobenour@...il.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Stephen Smalley <stephen.smalley.work@...il.com>,
        Eric Paris <eparis@...isplace.org>, selinux@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] SELinux: Always allow FIOCLEX and FIONCLEX

On 1/25/22 17:27, Paul Moore wrote:
> On Tue, Jan 25, 2022 at 4:34 PM Demi Marie Obenour
> <demiobenour@...il.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@...il.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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)