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 52B3CC4332F for ; Fri, 9 Dec 2022 16:29:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229563AbiLIQ3T (ORCPT ); Fri, 9 Dec 2022 11:29:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229470AbiLIQ3T (ORCPT ); Fri, 9 Dec 2022 11:29:19 -0500 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7097D85D0B for ; Fri, 9 Dec 2022 08:29:18 -0800 (PST) Received: from [192.168.1.108] (ip98-168-40-103.ph.ph.cox.net [98.168.40.103]) by linux.microsoft.com (Postfix) with ESMTPSA id 1A78720B6C40; Fri, 9 Dec 2022 08:29:18 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1A78720B6C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1670603358; bh=0jMIx88h53CDm+rzYbezxJEiroNeJv0850cmuo5ZijU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Tdjwj779kvFsTfaUxjki1VEoAYZvaAcKGvjkHay5U/tnmFo1+2DA0TBqMcupqHAkP McPa0U+R/umlijTkaTZNmf55p0kEm9bC70SjRt2GulLWUMRa6i0wwrtlcOs81SIK3D gOWkSWvDhG2uw2OqzGfGLAEZBr9DIrwdXF2pZyCY= Message-ID: <0397bf1e-415f-b045-5a6d-c12fde48a65a@linux.microsoft.com> Date: Fri, 9 Dec 2022 09:29:16 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [refpolicy3 RFC] Split broad file contexts Content-Language: en-US To: Chris PeBenito , SELinux Reference Policy mailing list References: From: Matthew Sheets In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: selinux-refpolicy@vger.kernel.org On 12/9/2022 9:09 AM, Chris PeBenito wrote: > In refpolicy2, we have several types, such as bin_t, that have file > contexts related to other modules, e.g.: > > /etc/acpi/actions(/.*)?            gen_context(system_u:object_r:bin_t,s0) > > /usr/lib/mailman/bin(/.*)?        gen_context(system_u:object_r:bin_t,s0) > > /var/mailman/bin(/.*)?            gen_context(system_u:object_r:bin_t,s0) > > > relate to acpi and mailman. > > Should we continue to put all of the bin_t labeling in files.cas or > should we split it back to the individual modules?  This was originally > done in refpolicy2 so users could look in a single place for everything > about bin_t for encapsulation.  This is nice for users, but not so nice > for maintenance and version control. > > Since cascade has the "extend" feature, we can split up the labeling > among relevant modules, and tooling can construct a single unified view > of the file contexts of bin_t and the like. > > For example, instead of this in file.cas: > > resource bin_t inherits executable { >   ...many fcs... >   file_context(/etc/acpi/actions(/.*)?, any); > } > > we have this in acpi.cas: > > extend bin_t { >   file_context(/etc/acpi/actions(/.*)?, any); > } > > > Thoughts? > > If I turn of a module I want as little residue as possible in other modules. I think using extend is the best option. Keep all relative types and labeling in the singular module so if it is not used we heavily reduce the possibility of unexpected labeling/access. The users should understand that a single cas file does not define the whole policy, so if they see something that may be "off" with labeling they may need to look further. And with the new tooling, looking further should be easy.