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

Jeff Johnson n3npq at nc.rr.com
Sat Jun 19 01:17:23 UTC 2004


Russell Coker wrote:

>----------  Forwarded Message  ----------
>
>Subject: Re: Where should an RPM install .te/.fc files?
>Date: Thu, 17 Jun 2004 02:48
>From: "mike at flyn.org" <mike at flyn.org>
>To: fedora-selinux-list at redhat.com
>
>  
>
>>>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




More information about the fedora-selinux-list mailing list