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
next 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).