All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.