From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 521ADC433FE for ; Mon, 14 Feb 2022 07:11:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241261AbiBNHLu (ORCPT ); Mon, 14 Feb 2022 02:11:50 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:33652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233544AbiBNHLt (ORCPT ); Mon, 14 Feb 2022 02:11:49 -0500 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 318D558E4D for ; Sun, 13 Feb 2022 23:11:41 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id e17so20941821ljk.5 for ; Sun, 13 Feb 2022 23:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g6DcfZ92QqbVDkAs+5onWxHYvjv4eWwkjyJIREZ2EHI=; b=FuHHJ7d7pv5aBhqmGSDZ49xksdbfDW1/UWVdzf9yzdMEbAxQdda/x670Ojs+8e87vM E5fimacLU+KLUtiJ2cK3H3h9q2Od2Wa3HStmrEe4GLWhoJMXtCuXFhb4dqCaGfaGoLfa 6AVvAon6gw93LvgE/YeBH7tl4vvAbD9rLhRg9ahUi2xDM8DdLqaQhOqJQSk3K11pmDc6 akX1kWkWmI4lNlIQ2Lsvh0WC+oHthoN4+WS1+MOBsIb8rqYJdkBO4YKpYfOrxvWUrXQv aDjJUdJB3QU7x8T+dNg3bPDQFZCSpBPoh+uLjsq8dYnftpAmFy1MGpgcKgD2oMiqkKRR VnEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g6DcfZ92QqbVDkAs+5onWxHYvjv4eWwkjyJIREZ2EHI=; b=fiArL4iw1Kh1MKIO2fl1GnSYg89AyaDlXe4xuIvXnkt06iwk29TGQDv5VeBETmzotf UGFiSALorDLbBux7NqmPh5SJRtlBpzsKjb/pfi8G64gHeOvivfrCMRCFYXvjBVzW1M/D gFDMxH0PoacDLYbL7LSiyvIfWj4jMSrHcGI7VkgpJbY4U6KtOD1ZLsuyPowfVqvfZwM5 DiosQ+wdqQ/vvU/+DEacakNMJZ1Rey5KWIW1NqIYNl4yDPCIH+KIjYr0j23S7jeYaOBL cGDTi+t1XIEXtJ0X8bOqS74292XRgWMvtenf1JJzr618yTFg9QICsCya2AzSnGpqru0i Gn5w== X-Gm-Message-State: AOAM533u+lqtqnnwSxVnes+aWuiOVfk3lKBnA7bnq8LIThz9VULzMZUd E5paLm2ec9adTAcV8OrlzZTC4GLUsXcwh4NA5l5OpS8VqUc3zg== X-Google-Smtp-Source: ABdhPJx7slpeRGSxnbPf6rrPFN41+RI0bP5E3hXma5RYfHdtnUcAjBwaynRftHeGXOGFN5zH+jAF0u9+ePiPHEGbbZI= X-Received: by 2002:a2e:a4ce:: with SMTP id p14mr1611442ljm.124.1644822699006; Sun, 13 Feb 2022 23:11:39 -0800 (PST) MIME-Version: 1.0 References: <4df50e95-6173-4ed1-9d08-3c1c4abab23f@gmail.com> <478e1651-a383-05ff-d011-6dda771b8ce8@linux.microsoft.com> <875ypt5zmz.fsf@defensec.nl> In-Reply-To: From: Jeffrey Vander Stoep Date: Mon, 14 Feb 2022 08:11:28 +0100 Message-ID: Subject: Re: [PATCH] SELinux: Always allow FIOCLEX and FIONCLEX To: William Roberts Cc: Dominick Grift , Chris PeBenito , Paul Moore , Demi Marie Obenour , Stephen Smalley , Eric Paris , SElinux list , Linux kernel mailing list , selinux-refpolicy@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Tue, Feb 8, 2022 at 3:18 PM William Roberts wrote: > > > > This is getting too long for me. > > > > > > > I don't have a strong opinion either way. If one were to allow this > > > using a policy rule, it would result in a major policy breakage. The > > > rule would turn on extended perm checks across the entire system, > > > which the SELinux Reference Policy isn't written for. I can't speak > > > to the Android policy, but I would imagine it would be the similar > > > problem there too. > > > > Excuse me if I am wrong but AFAIK adding a xperm rule does not turn on > > xperm checks across the entire system. > > It doesn't as you state below its target + class. > > > > > If i am not mistaken it will turn on xperm checks only for the > > operations that have the same source and target/target class. > > That's correct. > > > > > This is also why i don't (with the exception TIOSCTI for termdev > > chr_file) use xperms by default. > > > > 1. it is really easy to selectively filter ioctls by adding xperm rules > > for end users (and since ioctls are often device/driver specific they > > know best what is needed and what not) > > > >>> and FIONCLEX can be trivially bypassed unless fcntl(F_SETFD) > > > > 2. if you filter ioctls in upstream policy for example like i do with > > TIOSCTI using for example (allowx foo bar (ioctl chr_file (not > > (0xXXXX)))) then you cannot easily exclude additional ioctls later where source is > > foo and target/tclass is bar/chr_file because there is already a rule in > > place allowing the ioctl (and you cannot add rules) > > Currently, fcntl flag F_SETFD is never checked, it's silently allowed, but > the equivalent FIONCLEX and FIOCLEX are checked. So if you wrote policy > to block the FIO*CLEX flags, it would be bypassable through F_SETFD and > FD_CLOEXEC. So the patch proposed makes the FIO flags behave like > F_SETFD. Which means upstream policy users could drop this allow, which > could then remove the target/class rule and allow all icotls. Which is easy > to prevent and fix you could be a rule in to allowx 0 as documented in the > wiki: https://selinuxproject.org/page/XpermRules > > The questions I think we have here are: > 1. Do we agree that the behavior between SETFD and the FIO flags are equivalent? > I think they are. > 2. Do we want the interfaces to behave the same? > I think they should. > 3. Do upstream users of the policy construct care? > The patch is backwards compat, but I don't want their to be cruft > floating around with extra allowxperm rules. I think this proposed change is fine from Android's perspective. It implements in the kernel what we've already already put in place in our policy - that all domains are allowed to use these IOCLTs. https://cs.android.com/android/platform/superproject/+/master:system/sepolicy/public/domain.te;l=312 It'll be a few years before we can clean up our policy since we need to support older kernels, but that's fine.