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@xxxxxxxxxx [mailto:fedora-selinux-list- > bounces@xxxxxxxxxx] 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@xxxxxxxxxx > http://www.redhat.com/mailman/listinfo/fedora-selinux-list
