RE: .te file in RPMs
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
(410)290-1411 ext 134
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list