Re: Where should an RPM install .te/.fc files?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Russell Coker wrote:

----------  Forwarded Message  ----------

Subject: Re: Where should an RPM install .te/.fc files?
Date: Thu, 17 Jun 2004 02:48
From: "mike@xxxxxxxx" <mike@xxxxxxxx>
To: fedora-selinux-list@xxxxxxxxxx



I maintain an RPM that installs .te and .fc files.  In the past,
contributing to the system's SELinux policy could be done by installing
files in /etc/security/selinux/src/policy (I'm not sure this is right
to begin with):

%policy %{_sysconfdir}/security/selinux/src/policy/macros/pam_mount_macros.te



As noted, the path for installing *.fc and *.te files has changed.

Also, the %policy marker to include an absolute path in both the metadata header
as well as as a file in the payload is not necessary. The original goal was to have
rpm attempt "make reload" as well as setting file contexts, but there are too
many unsolved problems trying to install policy piece wise to attempt.


However, now policies may be in /etc/selinux/strict/src/policy/ or /
etc/selinux/targeted/src/policy/.  It is also possible that only one of
these directories exists.


rpm will create directories in order to install files, so you need not worry about
whether the directores exist. That is pure mechanism however, the comments below
apply to the intent, rather than the mechanics, of installing *.te and *.fc files.




I don't think that your macros file fits in with the targetted policy, and
I think that the general aims of the targetted policy don't involve that
sort of thing (but this hasn't been considered much so far).

It's probably best to install the files under only the strict directory.

It is also possible that only one of those directories exists.



Installing exclusively under the strict policy make sense. The things I am
explicitly allowing should probably already be allowed by the targeted
policy. However, what about the case where a user does not have the strict
policy installed? In this case my RPM will install its policy files to an
otherwise empty policy source tree. This may result in directories like
/etc/selinux/strict being orphans -- not owned by any RPM. Should this be
avoided somehow?



Even if rpm creates "orphan" directories on the path needed for installing a file,
the file context will still be set according to the currently configured regexes.


That still isn't quite correct behavior, as "orphan" directories under not under rpm control,
so any tools based on paths from an rpmdb will fail to change the "orphan" directory
paths.


The best way (imho) to add 3rd party *.te and *.fc files to either the targeted or strict trees
and avoid "orphan" directories is to add a file dependency on the parent directory.


E.g., add
Requires: /etc/selinux/targeted/src/pollicy
if installing a file into that directory. That will avoid any "orphan" directory problems
by forcing the package that owns the directory to be installed first. Note that
any dependency on the package that "owns" the directory is sufficient,
use a package rather than a file dependency if you wish.


There is still the problem of how and when "make reload" is to be done for the tree
when there are aadditional *.te and *.fc files being added. Probably the best answer for
right now is to attempt the same operation in %post that is attempted by the
selinux-policy-{targeted,strict} package itself.


There is the erasure reload case that needs to be handled in %postun as well.

Make sure you disambiguate erasure from upgrade by testing $1 in the %postun script.

Here's what ypbind does, every package with a %preun and/or %postun has examples:
if [ "$1" -ge 1 ]; then
/sbin/service ypbind condrestart > /dev/null 2>&1
fi
exit 0


The $1 argument is the number of instances of the pkg that will be
installed after the script is run, $1 == 0 is the pure erasure case, >= 1 is
the package upgrade case.

73 de Jeff


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux