lkml.org 
[lkml]   [2022]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] SELinux: Always allow FIOCLEX and FIONCLEX
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?

--
Sincerely,
Demi Marie Obenour (she/her/hers)
[unhandled content-type:application/pgp-keys][unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-01-30 04:40    [W:0.080 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site