On Thu, 2007-09-27 at 14:28 -0400, Richard Hally wrote: > Jesse Keating wrote: > > On Wed, 26 Sep 2007 20:52:45 -0600 > > Richi Plana <myfedora@xxxxxxxxxxxxxx> wrote: > > > >> Technically, those SELinux policies should come or be set by the > >> installation package. Would you happen to know what Fedora's stand on > >> that is? > > > > Not possible until SELinux upstream allows files to be written out with > > an unknown context or unabled context and switch to the new policy when > > it gets applied. > > > > Or something like that. Long long history and anger around this issue. > > > > Huh? > > http://fedoraproject.org/wiki/PackagingDrafts/SELinux > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules > The basic problem is that packages that contain SELinux policy often contain new types and the package installs files that should get those new types. So you end up with a chicken and egg problem - the package has the policy which needs to be installed before the package. There are a few solutions: 1) Separate packages for policy and apps - the app depends on the policy package. The problem is that the order packages are installed during a transaction can't be guaranteed, so this doesn't always solve the problem. It also means more packages. 2) Have rpm treat the policy specially - the rpm maintainers don't want to do this (I can understand). 3) Have rpm set contexts that aren't yet valid. This option was explored and there was even a kernel patch that would allow this. The fear is that it would allow a malicious package to create files with _any_ context that is not yet valid. It makes it difficult or impossible to constrain rpm. You could go back after the policy is installed and check for contexts that are still invalid and fix those. No decision was reached about how to handle the hole and nothing happened. The SELinux upstream developers (well, at least me) are willing to reconsider this proposal. 4) Allow the files to be laid down with whatever types the current policy gives them and relabel based on the new policy in post. This means touching every file twice (worst case) and also has some security concerns. 4 is a reasonable option except for performance concerns and that is what those packaging guidelines suggest (last I checked). Karl -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
