Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp762150ybh; Tue, 21 Jul 2020 07:23:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHgOj1wFKUPx6brvH0Skamjj+eouMPchjdZ/2DkrWSzcg4VN1oocc672olf/lBIEKGW7Tv X-Received: by 2002:a17:906:1a54:: with SMTP id j20mr25132736ejf.455.1595341392916; Tue, 21 Jul 2020 07:23:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595341392; cv=none; d=google.com; s=arc-20160816; b=uFxjGL00UBaY1VDhSSlzE8IsMzl6KpSflrXMxokWrVdnw5+VZ610TlwZH/Ckl/ZSAq YXXDcWGlaFpuawom8WWnNf957NCvG5aLC2qG8U1FcVRg+lOg/L5GrDi29P6q7NqzxZbD HFWa0ZLeJDLbMjTVisYbcX4HauVVsNoOe707K2ijyc5zbzldOSRwHFF25JE8g2HCqUW4 jtCaEa2II2q2c8ENFCGj1wHo1hHkiHNwk/RLtGSX0dlozkcoSCR3Dq+9nkG3K9m4zK2m fHC/RfSv0omTTe52N6pKbAPqXJrIoCupxm1ji4ccRMyB/ZuiOnX+x3US763d+sVQRq7+ 766g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=taBLdXg+av1bIty9AFMXQpSnme2lW5uF9jWVnSASCdM=; b=v8OYTpv3dAIyIROSWIdSKHyKXWerGA/5hYNf25a6AkeNwvsXXe7o3KuOsc6QqumpNB zBSzPG4g0wlpEG0VzBiSZesSK4nvMMyyPHtyiVCah8OyyTGRwBCJMKgW+7PO65M3b8rC YI9A5L6FuvG5c+EtxjIC+u/zLFDa536ZCbzqoFS2AXfOYu+TAQjtXEwrEGdvg+j25kiK 6xDV1SsAH5ArefhM1yyrAf4xDSZeFR0trqMQMiH+LMX4u9XeyDBBNjS8Sj9U8jNjkdjv GFgFy9OPbEMBn/WPucuMwvHYAEBHj9UPpTnk+myYirngqbyNatutI18E/OC0ttjOOR1i gnnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=RWBR0Li+; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lu12si12341942ejb.269.2020.07.21.07.23.07; Tue, 21 Jul 2020 07:23:12 -0700 (PDT) Received-SPF: pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=RWBR0Li+; spf=pass (google.com: domain of selinux-refpolicy-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=selinux-refpolicy-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ieee.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728913AbgGUOWv (ORCPT + 15 others); Tue, 21 Jul 2020 10:22:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726710AbgGUOWu (ORCPT ); Tue, 21 Jul 2020 10:22:50 -0400 Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68122C061794 for ; Tue, 21 Jul 2020 07:22:50 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id 6so16254679qtt.0 for ; Tue, 21 Jul 2020 07:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=taBLdXg+av1bIty9AFMXQpSnme2lW5uF9jWVnSASCdM=; b=RWBR0Li+0j5+6zd5GKE3kTDPXFQV++ksQfZlWdaiOUTrN1UJ+Zfyz04tmE5yi2EyBk x0LIxpDgK681XNEXlW/7FGDQQVMhvxAc39FakeXm3ZPurISVvQtV8MecVgTVwWZNN4xV RTsI0rGo2CZhyqhZkUPNbH+ywcoUQiijb5Hp8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=taBLdXg+av1bIty9AFMXQpSnme2lW5uF9jWVnSASCdM=; b=B0rRnm9XjZ64BsNUrfnzgMY6Gbc28AwpxPJW3NWyKVvi3iA87IRcFZtmkMHgjDmiXo TKFRihEUlzRJ51qd+eAwLQlpF7fqrisgEHXGHs0vfC+wanS/NK/iCHmEhdyzBQCrUVCI hBzwXPTkdm/AoGmd4fsxqWBJNT219hiNEYm2Mh1o6Ar0HkEeGwli8YgWIukMF/3TWLbu Ax38jbRDUAXhMgS3PlGwC8+BFqRVYSsCv/ilY5/7yHYLfB2xpDSAc/ZSb7Ma5ljq0FKs D6qhuqY++W2ayIo23H8YvQCihhW30AZ6GDRPq/5JTnlLONi1W3r2CsejQ6hRTJAsM4yC z+Ow== X-Gm-Message-State: AOAM533PjiT1ye1XxzFfCOd7JQhBeln1dIeNhInzbkExH6rmOp77yP0d q3ruvXOnXDOaiZ+hDDm3uDYckoXtLQc= X-Received: by 2002:ac8:45d1:: with SMTP id e17mr30404484qto.159.1595341369250; Tue, 21 Jul 2020 07:22:49 -0700 (PDT) Received: from fedora.pebenito.net (pool-108-15-23-247.bltmmd.fios.verizon.net. [108.15.23.247]) by smtp.gmail.com with ESMTPSA id a193sm2338173qkc.102.2020.07.21.07.22.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jul 2020 07:22:48 -0700 (PDT) Subject: Re: Are we on the wrong track? To: bauen1 Cc: selinux-refpolicy@vger.kernel.org References: <3243717.6S2XvbbdUs@liv> <578d7c7c-cb41-b224-2758-144aa9b5c1ad@ieee.org> <2469682.qIgoumM3a6@liv> <03249797-9067-34f1-c4ec-39f163fb9042@gmail.com> From: Chris PeBenito Message-ID: <63612ad4-967b-18b0-2667-1f6b74c19e5d@ieee.org> Date: Tue, 21 Jul 2020 10:22:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <03249797-9067-34f1-c4ec-39f163fb9042@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: selinux-refpolicy-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 7/19/20 3:29 PM, bauen1 wrote: > On 7/16/20 4:09 PM, Chris PeBenito wrote: >> This behavior depends on the type of the file. If you end up with a staff_u:object_r:etc_t context, the user separations don't apply since this is not a user file. > > I'll have to take another look at it then. > >> We used to have role based separations but it was encoded into the TE rules and generated an enormous amount of rule duplication.  There are some remaining examples of this, e.g. in the su and sudo policies (staff_su_t, sysadm_su_t). > > There are cases where these will still be necessary, mainly when type transitions to the user type are required, but some could be eliminated. Right, there will always be needs like this. Which ones could be eliminated? I can't immediately think of an example. >> When the default_* statements were implemented I started to reimplement the role-based separations using the role, but then I lost the work before I finished.  I don't think it is too involved, since it may be as simple copying the UBAC infrastructure and tweaking it to work on roles. > > I've also worked on implementing RBAC and RBACSEP for refpolicy (A bit messy: https://github.com/bauen1/refpolicy/tree/rbac) . If this becomes a goal to implement, perhaps https://github.com/SELinuxProject/refpolicy/pull/203 could be merged first. It's a goal, but it hasn't been a high enough priority for someone invest the time in it. -- Chris PeBenito