Re: .te file in RPMs

[W. Michael Petullo]

> > I would like to learn the proper way for a package to install an
associated
> > te file, rebuild the SELinux policy and load the new policy. 
> Could 
someone
> > point me in the proper direction?  Is there something better than
> "make
> > reload" in the post-install script? 
 
>  Currently there is no proper method.
>  
>  Loading the policy in the post-install alone won't do it.  Any policy that
>  is significant will add new file types, and the package which contains the 
>  policy (*) will have files that need to be labeled with those types.  This 
>  means that you would have to not only load the policy but label the files
>  in the post-install script.  This is ugly. 
Does this mean that this is not a blocker for Fedora Core 2, as the entry in
the SELinux roadmap at http://fedora.redhat.com/projects/selinux/ seems to
imply ("Fedora Core 2 release may happen after item 9 or 10...")?

--
Mike

.te file in RPMs

[Jeff Johnson]

mike(a)flyn.org wrote:

> >>I would like to learn the proper way for a package to install
> an
> >>      
> >>
> associated
>   
>
> >>te file, rebuild the SELinux policy and load the new policy.  Could
> >>      
> >>
> someone
>   
>
> >>point me in the proper direction?  Is there something better than "make
> >>reload" in the post-install script?
> >>      
> >>
>  
>   
>
> >Currently there is no proper method.
> >
> >Loading the policy in the post-install alone won't do it.  Any policy that
> >is significant will add new file types, and the package which contains the 
> >policy (*) will have files that need to be labeled with those types.  This 
> >means that you would have to not only load the policy but label the files
> >in the post-install script.  This is ugly.
> >    
> >
>
> Does this mean that this is not a blocker for Fedora Core 2, as the entry in
> the SELinux roadmap at http://fedora.redhat.com/projects/selinux/ seems to
> imply ("Fedora Core 2 release may happen after item 9 or 10...")?
>   
>  
The means to save *.te files exists in rpm-4.3 and later.

In %files, adding %policy before a path will load the contents of the 
file into metadata.

If the path is relative, then it's relative to the build directory, and 
the contents goes only
into the header.

If the path is absolute, then it's relative to $RPM_BUILD_ROOT, and the 
contents goes
into both the header and the payload.

Now, all that being said, the entire mechanism is gonna be scrapped and 
redone, for
several reasons:
    1) policy is now composed of both macros and *.te files (and *.fc, 
handled already), and has policy versions
         and booleans and probably other "stuff" in the works that needs 
to be accomodated.
     2) policy is still changing too rapidly for it to make sense to 
burn into package headers that are about to be
          released as Fedora Core 2, which will persist long beyond the 
development cycle.

So it's time to back up and redesign how policy should be packaged into rpm.

So, "Not a blocker" afaik.

73 de Jeff

.te file in RPMs

[Karl MacMillan]

First, I want to give a little background before I make some specific
comments on this discussion. We (Tresys) are working on support for binary
policy modules. We hope to create an infrastructure for the management of
the system policy in a modular fashion. We envision this infrastructure
could be used by other tools (like RPM) and will provide a consistent and
safe mechanism to facilitate and control modification to the system policy.

These modules will be a binary package that has a piece of the policy,
information of the requirements of the module (i.e. which object class,
types, roles, etc it references but doesn't declare), an optional labeling
policy, and an optional copy of the policy source. The existing tools like
checkpolicy and loadmodule will be modified to support this work.

This discussion of how rpm will interact with policies is, I think, a good
opportunity for us to discuss our current plans and get some feedback so
that hopefully our work can be used by rpm. Also, this work is what #10 on
the selinux todo for Fedora refers to.


>  -----Original Message-----
>  From: fedora-selinux-list-bounces(a)redhat.com [mailto:fedora-selinux-list-
>  bounces(a)redhat.com] On Behalf Of Jeff Johnson
>
>  Now, all that being said, the entire mechanism is gonna be scrapped and
>  redone, for
>  several reasons:
>      1) policy is now composed of both macros and *.te files (and *.fc,
>  handled already), and has policy versions
>           and booleans and probably other "stuff" in the works that needs
>  to be accomodated. 
I know that rpm can handle labeling of files that it installs, but I'm not
certain that is complete support for labeling (maybe *.fc being handled
means more this and I'm not aware of the additional support). It seems that
providing a database of labeling decisions (e.g. a global file_contexts
file) is necessary and helpful. So, for example, when an rpm is installed
into /opt instead /usr the file_contexts file has entries for the files that
rpm installed with the correct location. This is necessary, at least, for
support a full 'make relabel' style relabeling of the filesystem.

As for the other "stuff", this seems to boil down to rpm supporting the
installation of multiple policies based on different criteria. This is
useful for both versioning (for handling backward compatibility for
booleans, etc) and for supporting policies with different goals in 1 rpm.
For example, a single rpm might provide a very permissive policy for general
use and a tightly locked down policy for more security sensitive installs. A
global security setting might then control which type of policy gets
installed.

>       2) policy is still changing too rapidly for it to make sense to
>  burn into package headers that are about to be
>            released as Fedora Core 2, which will persist long beyond the
>  development cycle.
>   
This problem seems more general to me. In some circumstances, policy may be
orthogonal to what rpm provides and it seems like a good idea to think about
some ways to support this. For example, I can envision the need to support
policies that are distributed separately from rpms. A company might have a
very strict security policy for its servers, including an SELinux policy,
that they want to install on all of their servers. In this case, an rpm
upgrade might modify the policy in an undesirable way. I don't have any good
answers for this, but think it is important to think about the relationship
between rpms (applications) and policy and how closely they should be
coupled.

Karl

>  So it's time to back up and redesign how policy should be
> packaged into
>  rpm.
>  
>  So, "Not a blocker" afaik.
>  
>  73 de Jeff
>   
Karl MacMillan
Tresys Technology
http://www.tresys.com
[phone] ext 134

>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list