blocked by a missing dependency as to the EPEL audience, filed at:

https://bugzilla.redhat.com/show_bug.cgi?id=1509383

1. Why are there so many references to "Red Hat", especially the "Red Hat recommends, to set up custom Git repository for the policy." is weird to me ...
2. Why are there some actions in %pre, %post and %postun? Shouldn't this be implemented by some filetriggers [1]?

blocked by a missing dependency as to teh EPEL audience, filed at:
https://bugzilla.redhat.com/show_bug.cgi?id=1509383

Patch sent to SELinux upstream.

Why are there so many references to "Red Hat", especially the "Red Hat recommends, to set up custom Git repository for the policy." is weird to me ...

You are right, it's fixed now.

Why are there some actions in %pre, %post and %postun? Shouldn't this be implemented by some filetriggers [1]?

Probabably I don't understand your point, but in these actions are implemented as rpm macros and we ship it with selinux-policy rpm package and macros can be find here:
https://github.com/fedora-selinux/selinux-policy-macros

Thanks,
Lukas.

%post
%selinux_modules_install -s %{selinuxtype} %{_datadir}/selinux/packages/%{modulename}.pp.bz2
%selinux_set_booleans -s %{selinuxtype} %{selinuxbooleans}

%postun
%selinux_modules_uninstall -s %{selinuxtype} %{modulename}
%selinux_unset_booleans -s %{selinuxtype} %{selinuxbooleans}

I think it was about this one.

http://rpm.org/user_doc/file_triggers.html

Basically we should try to automate as much as we can.

%if 0%{?fedora}
Requires(post): policycoreutils-python-utils
%else
Requires(post): policycoreutils-python
%endif

I would really love to see this replaced by %{?selinux_requires}

For example, you suggest following:

%pre
%selinux_relabel_pre -s %{selinuxtype}

But this could be done once on the beginning of the transaction if some file such as %{_datadir}/selinux/packages/%{modulename}.pp.bz2 is installed by some package. It does not need to be run for every installed package, or does it? So %transfiletriggerin could be used to achieve this.

Nobody would need to use the %pre section and the whole SELinux packaging would become easier.

Similarly %selinux_modules_{,un}install could be run when %{_datadir}/selinux/packages/%{modulename}.pp.bz2 is {,un}installed, just once per transaction ...

We discussed this at last weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-09/fpc.2017-11-09-17.00.txt):

• x726 Review for SELinux Independent Policy packaging Draft (geppetto,
  17:36:16)
• LINK: https://pagure.io/packaging-committee/issue/724
  (ignatenkobrain, 17:54:26)

triggers have historically been 'rare' in packaging, as the (rather old) LSB leve of the RPM packaging format did not support them

This in turn was an artifact of the lack of alien, and the then Debian .DEB format of the era not having such [rather more resembling the old HP 'depot' format, or Slackware 'unrolling tarballs, or Solaris' approach

Times change

I don't see that 'trigger' constructs have much uptake, however of an archive of 1764 .SPEC files, I see only these usages:

[herrold@centos-7 SPECS]$ grep trigger * | grep "%\%" | awk -F: {'print $1'} | sort | uniq
eric.spec
mathml-fonts.spec
rpmdevtools.spec
sendmail.spec
[herrold@centos-7 SPECS]$

@herrold Are you sure your query is correct?

My query was run in the 'unpacked' spec file directory of my local builder. Periodically, I clean out that tree to recover space, and so, it is in no way a statistically, representative, nor a 'all packages, nor any other form of sample, other than a 'pile pf packages' sample

I've been on the relevant LSB working group for ... a long time -- I went back and forth with then chair, Ted Tso, on the exclusion of triggers long ago on the mailing lists (RPM and LSB), and also in the weekly LSB working group calls. That said, I have opened a fresh ticket there to see if I cannot get the limitation re-considered

http://refspecs.linuxfoundation.org/LSB_1.2.0/gLSB/swinstall.html

https://www.redhat.com/archives/rpm-list/2001-July/msg00042.html

%if 0%{?fedora}
Requires(post): policycoreutils-python-utils
%else
Requires(post): policycoreutils-python
%endif

I would really love to see this replaced by %{?selinux_requires}

Make sense,

I created new macro selinux_requires and will included in all selinux-policy rpm builds for f26+

For example, you suggest following:
%pre
%selinux_relabel_pre -s %{selinuxtype}

But this could be done once on the beginning of the transaction if some file such as %{datadir}/selinux/packages/%{modulename}.pp.bz2 is installed by some package. It does not need to be run for every installed package, or does it? So %transfiletriggerin could be used to achieve this.
Nobody would need to use the %pre section and the whole SELinux packaging would become easier.
Similarly %selinux_modules{,un}install could be run when %{_datadir}/selinux/packages/%{modulename}.pp.bz2 is {,un}installed, just once per transaction ...

Hi Vit,

If SELinux policy is part of some rpm package, there is also file context file, which assign SELinux label to objects on system. e.g:
/etc/docker(/.*)? gen_context(system_u:object_r:container_config_t,s0)

In %pre phase using %selinux_relabel_pre we save database of all these file contexts, then new SELinux policy is installed and in %post phase using %selinux_relabel_post we check diff of these databases and then we set correct label for files added by new policy. So we need this actions in every pre and post phase during installation of rpm package with own custom SELinux policy.

We do this to speedup the process of installation because we fix labels only on files from difference of these databases.

I hope it clear now.

Guidelines updated, I removed from preamble all requires and created new rpm macro called %{selinux_requires}. This change will be part of new selinux-policy builds.

@lvrabec, you need to use %{?selinux_requires}, note ? there.

@lvrabec, you need to use %{?selinux_requires}, note ? there.

Fixed.

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-11-29/fpc.2017-11-29-18.00.txt):

• x726 Review for SELinux Independent Policy packaging Draft (geppetto,
  18:08:38)
• Shouldn't be recommending external services. (geppetto, 18:15:48)

Hi James,

What you mean by external services?

Thanks,
Lukas.

@lvrabec

in your wiki draft, I see a fragment:

The %prep and %install Section

%pre
%selinux_relabel_pre -s %{selinuxtype}

Does a build system NOT building as root, have sufficient rights to do such a relabeling?

@lvrabec

Also I see:

:warning: 
Setting some generic booleans can open security holes in the system.

Could you please add a link pointing to a write-up on this, as the target reader is a inexperienced packager, not already knowing what traps and pitfalls exist

@lvrabec

The Resources at the bottom of the document are useful, but are there no acceptable write-ups in Red Hat, or Fedora documentation space which cover the same areas? A blog post is ephemeral, and may disappear or be invisibly revised at any time.

This is not speculation or hypothetical. I had this happen, as to a SElinux resource, upon which I filed a bug, after a US political election, with the new officeholder breaking old links without compatibility

@lvrabec
The Resources at the bottom of the document are useful, but are there no acceptable write-ups in Red Hat, or Fedora documentation space which cover the same areas? A blog post is ephemeral, and may disappear or be invisibly revised at any time.
This is not speculation or hypothetical. I had this happen, as to a SElinux resource, upon which I filed a bug, after a US political election, with the new officeholder breaking old links without compatibility

Okay, I'll remove resources from the wiki document.

@lvrabec
Also I see:
⚠
Setting some generic booleans can open security holes in the system.

Could you please add a link pointing to a write-up on this, as the target reader is a inexperienced packager, not already knowing what traps and pitfalls exist

We don't have any article about this, also fedora SELinux documentation not mentioning this. I can write it but it will be some kind of blog post.

@lvrabec
in your wiki draft, I see a fragment:
The %prep and %install Section

%pre
%selinux_relabel_pre -s %{selinuxtype}

Does a build system NOT building as root, have sufficient rights to do such a relabeling?

These macros are used during installation process, where database of all labeled objects on system is stored before installation of custom SELinux policy, and then it's compared after the installation of custom policy and diff of these files are used to set right SELinux contexts.

A couple of comments:
1. the packaging guidelines should only cover how to include an independent selinux policy in a package, not how to actually create the policy
2. the Makefile contains rules for processing .te and .pp files, but current selinux policy tools can work with .cil format directly, this is not mentioned
3. (un)setting any selinux booleans should be authorized by FESCo

@lvrabec

an article on commonly observed, but 'dangerous' SELinux booleans would be very welcomed by me

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-12-13/fpc.2017-12-13-18.00.txt):

• x726 Review for SELinux Independent Policy packaging Draft (geppetto,
  18:10:40)
• FPC generally agree we don't want to be documenting selinux policy
  files. (geppetto, 18:16:32)

@lvrabec

The Resources at the bottom of the document are useful, but are there no acceptable write-ups in Red Hat, or Fedora documentation space which cover the same areas?

I was not unhappy with the links, and saved a copy, and added some 'follows' to my RSS reader. I just think that links in a wiki 'rot' and are forgotten except to Google spidering indexing [and that only once they have gone stale ;) ]

But I would really rather see such good content incorporated into something like the SELinux User's and Administrator's Guide so that it is regularly, and formally maintained

If this needs a formal Bugzilla entry, please let me know

A couple of comments:
1. the packaging guidelines should only cover how to include an independent selinux policy in a package, not how to actually create the policy

I tried to create document how to ship already existing policies, writing new SELinux policy is out of scope for this document.

1. the Makefile contains rules for processing .te and .pp files, but current selinux policy tools can work with .cil format directly, this is not mentioned

If you have policies in CIL, you don't need to use Makefile, but directly load these policies using semodule. See difference

.pp
{.te, .fc, .if} -> Makefile -> .pp -> semodule -i .pp

.cil
.cil -> semodule -i *.cil

1. (un)setting any selinux booleans should be authorized by FESCo

This can be good idea, but in document is mentioned that we as SELinux team can be in consulting role.

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-12-13/fpc.2017-12-13-18.00.txt):

x726 Review for SELinux Independent Policy packaging Draft (geppetto,
18:10:40)
FPC generally agree we don't want to be documenting selinux policy
files. (geppetto, 18:16:32)

Agree that writing policies is out of scope for this document.

james,
Is there any other issue, what's blocking this draft?

Thanks,
Lukas.

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2018-01-24/fpc.2018-01-24-18.22.txt):

• x726 Review for SELinux Independent Policy packaging Draft (geppetto,
  18:42:55)
• ACTION: tibbs Will work with you to try to extract the guideline
  parts of the document (removing stuff about setting up github etc.)
  (geppetto, 18:46:43)

@tibbs

Could you contact me and we can discuss witch parts should be removed.

Thanks,
Lukas.

It's basically a matter of me finding the time to go through the draft and identify the parts which are actually packaging guidelines.

All that should be in the packaging guidelines are instructions how you take a couple of policy files which are either checked in alongside the specfile or in a tarball that comes from an external repository and get those applied. Does that go in a separate package or in the main package? What scriptlets (if any) are needed to get the new policy applied to everything? Are there restrictions on what a policy can and cannot modify? Are there rules about adding transitions to existing domains, or adding new patterns which map to existing contexts, or file context equivalencies or anything else of that nature?

So in some sense the "Creating the Spec File" is a start but even then, I think more normal use case would be to include the policy in one package with the software it applies to.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-12/fpc.2018-04-12-16.00.txt):

• x726 Review for SELinux Independent Policy packaging Draft (geppetto,
  16:11:45)
• ACTION: redi will look at helping tibbs, but not before next week
  (geppetto, 16:24:55)

From the draft:

The Preamble
# defining macros needed by SELinux
%global selinuxtype targeted

It seems like we need to have one spec file for one %selinuxtype... wouldn't it be better to have one spec file for all policies, and have sub-packages for all the %selinuxtypes?

Also note the

%pre
%selinux_relabel_pre -s %{selinuxtype}
...
%post
%selinux_modules_install -s %{selinuxtype} %{_datadir}/selinux/packages/%{modulename}.pp.bz2
...
%posttrans
%selinux_relabel_post -s %{selinuxtype}

The %selinux_relabel_{pre,post} use the same file as stored context (namely /var/lib/rpm-state/file_contexts.pre), which means that the file might get updated several times in trasaction - and then used several times in posttrans - but the file then reflects only the last %pre call in transaction. I'd suggest to use:

%pre
%selinux_relabel_pre -s %{selinuxtype}
...
%post
%selinux_modules_install -s %{selinuxtype} %{_datadir}/selinux/packages/%{modulename}.pp.bz2
%selinux_relabel_post -s %{selinuxtype}

Also, consider example of foo-selinux custom policy package for set of packages related to package (module) foo. If some selinux-policy is loaded into kernel, it is absolute necessary to have installed foo-selinux package - otherwise foo packages won't work. On the other hand, if there's no selinux-package (e.g. container scenario) I never want to have foo-selinux installed. Guidelines should also instruct us how to depend on foo-selinux correctly.

Recap https://fedoraproject.org/wiki/Talk:PackagingDrafts/SELinux_Independent_Policy

@praiskup
Thanks for recap!

Adding to my todo to answer all things.

@lvrabec any news here?

Also we've moved all our wiki pages to this git repository, so once you have something -- just send pull request ;)

ten months later, the asserted fis for my bug filed long ago still is not pushed out

locally

[herrold@centos-7 ~]$ rpm -q policycoreutils
policycoreutils-2.5-22.el7.x86_64
[herrold@centos-7 ~]$ date
Mon Sep 24 11:48:18 EDT 2018
[herrold@centos-7 ~]$

claimed to be addressed in
policycoreutils-2.5-23.el7

I would be delighted to test the outline, but the fix on my blocker from Nov 2017 is still not pushed

I have no idea at all what the Fedora packaging committee is supposed to be able to do about that.

In any case, after several hours of unpleasantness I now have a standalone selinux policy that I'm going to work on packaging (for shellinabox). That will give me a chance to go through the proposal and see what I can pull out of it.

Hi All,

Sorry for late reply. Together with vmojzis we're working on this and will try to incorporate all your feedback.

@tibbs
That's great, please try It and let us know.

Lukas.

@praiskup thank you for the recap. I added some comments hopefully answering most of your questions and updated the draft accordingly.
Could you please have a look and let us know of any issues?

It would be cool if you would send Pull Request against our repo instead of touching wiki because someone will have to do manual conversion and it is impossible to comment in wiki inline.

Thanks for the answers, and for the updates. I think it is pretty good at this point, good job.

Few missing steps:

When a git repository with already contains a product SELinux policy, the product maintainer should create a subpackage for it. See Preparing sources for the Policy Git Repository

It doesn't quite make sense, are we talking about package git or upstream source git? The link doesn't work either.

%attr(0644,root,root) %{_datadir}/selinux/devel/include/%{moduletype}/ipp-%{modulename}.if

That %attr macro shouldn't be needed, mode is set by the install command above.

distro_stup()

Should be distro_stub..., but this paragraph should probably cite some upstream definition what is stub policy and how the inheritance works - that part is pretty hard to follow.

Requires: (%{name}-selinux if selinux-policy-base)

I'm not sure the conditional works with artificial Provides: selinux-policy-base, I'll check. But if the independent policy package (say, foo-selinux) provides a targeted policy, it should depend on the selinux-policy-targeted; ditto for the package (say foo-selinux-mls) which provides mls package.

Also please consider putting this line also into the "The Preamble" section because that is probably "template" to be C&P'ed.

install -m 0644 %{modulename}.pp.bz2 %{buildroot}%{_datadir}/selinux/packages

This instruction seems to be correct, but what if I had both mls and targeted policies? The %selinuxtype should play a role in the final installation path IMO.

if [ $1 -eq 0 ]; then
%selinux_modules_uninstall -s %{selinuxtype} %{modulename}
fi

Why not to remove the if [ $1 ... part and let the check be done by %selinux_modules_uninstall?

%files
%attr(0644,root,root) ...

That %attr is probably not needed

%ghost %{_sharedstatedir}/selinux/%{selinuxtype}/active/modules/200/..

This is pretty confusing, the 200 in parciular. During my experiments with the policy I was facing some warnings/errors mentioning numbers like 200 or 400... Some note related to the constants would be nice.

Setting Booleans During an Product Policy Installation

Any boolean seem to be blindly set or unsed, no matter whether other selinux package turns that on or off; it is not very nice but that's FTR (I wish we could just declaratively say "hey, we require this boolean to be set to this value" - without being responsible for flipping the values manually).

Port Labeling

This part pretty brittle. Seems like the paragraph suggests doing %{_sbindir}/load_policy manually, but it is wrapped into %selinux_modules_install in other sections. The %relabel_files doesn't seem to be defined.

Building a Package with an Own Product SELinux Policy

This part doesn't seem to fit into the SELinux related howto; it is more a description of a generic packaging habit.

It would be cool if you would send Pull Request against our repo instead of touching wiki because someone will have to do manual conversion and it is impossible to comment in wiki inline.

@ignatenkobrain
So I should convert the content of the wiki to AsciiDoc and create a pull request adding the guidelines to https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages ?

@ignatenkobrain
So I should convert the content of the wiki to AsciiDoc and create a pull request adding the guidelines to https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages ?

This would be awesome!

https://pagure.io/packaging-committee/pull-request/814

@praiskup
Thank you for the missing steps. I fixed most of them in the draft and here is my take on the rest:

Also please consider putting this line also into the "The Preamble" section because that is probably "template" to be C&P'ed.

It is, but it should be used in foo.spec, not foo-selinux.spec (or in corresponding preambles if they are described in the same spec file).

if [ $1 -eq 0 ]; then
%selinux_modules_uninstall -s %{selinuxtype} %{modulename}
fi

Why not to remove the if [ $1 ... part and let the check be done by %selinux_modules_uninstall?

I prefer the explicit condition so that it's obvious that the macro is only executed when removing the package. Also the macro is general and could be placed elsewhere in the spec file (different phase).

Setting Booleans During an Product Policy Installation

Any boolean seem to be blindly set or unsed, no matter whether other selinux package turns that on or off; it is not very nice but that's FTR (I wish we could just declaratively say "hey, we require this boolean to be set to this value" - without being responsible for flipping the values manually).

Booleans normally shouldn't be unset during installation since it usually does not allow new rules (it can, but that functionality is rarely used).
We currently do not have such a mechanism, but you are right that it would simplify things.

So, wondering if we could revive this and possibly get a final version into the current guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/

I'll also bring up an issue - during install the following is emitted:

libsemanage.semanage_direct_install_info: Overriding cobbler module at lower priority 100 with module at priority 200.

I believe we don't want output during install, so perhaps a > /dev/null is needed on the %selinux_modules_install/uninstall lines?