selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominick Grift <dominick.grift@defensec.nl>
To: selinux@vger.kernel.org
Subject: libsepol regressions
Date: Sun, 01 Aug 2021 16:22:34 +0200	[thread overview]
Message-ID: <871r7dtfbp.fsf@defensec.nl> (raw)


Fedora recently decided to pull in various libsepol patches from
master[1]

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

             reply	other threads:[~2021-08-01 14:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01 14:22 Dominick Grift [this message]
2021-08-01 19:23 ` libsepol regressions Dominick Grift
2021-08-02  6:58   ` Dominick Grift
2021-08-02  8:58     ` Dominick Grift
2021-08-02 14:50 ` James Carter
2021-08-02 15:12   ` Dominick Grift
2021-08-03  9:49     ` Dominick Grift
2021-08-03 13:35       ` James Carter
2021-08-03 14:19         ` Dominick Grift
2021-08-04  7:35   ` Dominick Grift
2021-08-04 13:33     ` James Carter
2021-08-04 13:49       ` Dominick Grift

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871r7dtfbp.fsf@defensec.nl \
    --to=dominick.grift@defensec.nl \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).