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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD934C4338F for ; Sun, 1 Aug 2021 19:23:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C696460234 for ; Sun, 1 Aug 2021 19:23:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229848AbhHATXs (ORCPT ); Sun, 1 Aug 2021 15:23:48 -0400 Received: from agnus.defensec.nl ([80.100.19.56]:54430 "EHLO agnus.defensec.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbhHATXr (ORCPT ); Sun, 1 Aug 2021 15:23:47 -0400 Received: from brutus (brutus.lan [IPv6:2001:985:d55d::438]) by agnus.defensec.nl (Postfix) with ESMTPSA id 5D1482A006A for ; Sun, 1 Aug 2021 21:23:38 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 agnus.defensec.nl 5D1482A006A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=defensec.nl; s=default; t=1627845818; bh=HOk5QK86u+/rA28j2AswXElyAT4RZ56E39qDPfjUREI=; h=From:To:Subject:References:Date:In-Reply-To:From; b=VEo/Eq84br6RVEh5fiDpq1bm7Ez/4lwjiSlGpjhNE1bFqs4eyCudREW6fW3BThbYD VyeW78sn54Py6JSjV7ynlVL9nGRoOBOBNecLXrRzQzC3iYQbeB4moLvusfKC8TgFFk ALrp+CSmECYO0noC/BT3jDFsQVDMol1Z8iS52jmY= From: Dominick Grift To: selinux@vger.kernel.org Subject: Re: libsepol regressions References: <871r7dtfbp.fsf@defensec.nl> Date: Sun, 01 Aug 2021 21:23:35 +0200 In-Reply-To: <871r7dtfbp.fsf@defensec.nl> (Dominick Grift's message of "Sun, 01 Aug 2021 16:22:34 +0200") Message-ID: <87k0l57yvc.fsf@defensec.nl> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org Dominick Grift writes: > Fedora recently decided to pull in various libsepol patches from > master[1] Here are two examples (test1.cil and test2.cil) that I think demonstrate some of my issues. Comment out the ";;the culprit" blocks to see it fail. In the test1.cil scenario I previously was able to get around this by re-declaring the macro. In the test2.cil scenario I previously was able to get around this by re-declaring the block. I do not mind not being allowed to re-declare macros and blocks but then I would appreciate if I could use "in" to insert into them instead. If I cannot either re-declare nor "insert into" then templates become pretty useless due to the limitations. --- cat > test1.cil < test2.cil < > My policy has broken down in various way's. Some changes make sense but > some others I have issues with. > > An example of something I never expected to be allowed in the first > place is re-declarations of blocks and recent changes exposed some instances > where I declared blocks multiple times and got away with it. > > However I also encountered issues that i am not sure how to deal > with. > > re-declarations of macros are no longer allowed: > > Take this example: > https://github.com/DefenSec/dssp5/blob/dev/src/dev/termdev.cil > > Here I inherit a set of macros from the > "file.all_macro_template_chr_files" template and then I override some of these > macros by manually re-declaring them with slighty different content (the > xperm rules are appended). > > This use to be allowed but I am no longer allowed to redeclare macros. > > This would not necessarily be a big problem IF this would instead work: > > diff --git a/src/dev/termdev.cil b/src/dev/termdev.cil > index 1c0fe66..4f067db 100644 > --- a/src/dev/termdev.cil > +++ b/src/dev/termdev.cil > @@ -3,21 +3,9 @@ > > (block termdev > > - (macro appendinherited_all_chr_files ((type ARG1)) > - (allow ARG1 typeattr appendinherited_chr_file) > - (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > - > - (macro readwriteinherited_all_chr_files ((type ARG1)) > - (allow ARG1 typeattr readwriteinherited_chr_file) > - (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > - > (macro type ((type ARG1)) > (typeattributeset typeattr ARG1)) > > - (macro writeinherited_all_chr_files ((type ARG1)) > - (allow ARG1 typeattr writeinherited_chr_file) > - (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > - > (typeattribute typeattr) > > (blockinherit .file.all_macro_template_chr_files) > @@ -33,3 +21,12 @@ > > (allow typeattr termdev.typeatt > (chr_file (not (execmod mounton)))))) > + > +(in termdev.appendinherited_all_chr_files > + (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > + > +(in termdev.readwriteinherited_all_chr_files > + (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > + > +(in termdev.writeinherited_all_chr_files > + (allowx ARG1 typeattr (ioctl chr_file (not (0x5412))))) > > But the above in-statements cannot be resolved. > > This is not the only instance where this approach does not work. I also > have templates that declare blocks. I use to be allowed to re-declare > these blocks so that I could add to them but this is no longer > allowed. However these blocks also cannot be resolved outside of the > templates, so I cannot use "in" to reference them. > > It seems as if the "in" blocks are resolved before the "blockinherit" > blocks are expanded. > > [1] https://src.fedoraproject.org/rpms/libsepol/c/c59879b8aa30ceb601ac4e449ee5e958c6659fbc?branch=rawhide -- gpg --locate-keys dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift