> From: Joe Nall [mailto:joe@xxxxxxxx] > > On Jul 13, 2009, at 12:40 PM, Joshua Brindle wrote: > > > Joe Nall wrote: > >> > >> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote: > >> > >>> On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@xxxxxxxxxx> wrote: > >>> > >>>>> From: James Carter [mailto:jwcart2@xxxxxxxxxxxxx] > >>>>> > >>>>>> Its alot worse than that. What about files on backup > >>>>> drives? Offline drives? > >>>>>> transient files that will get relabeled to something > >>>>>> inappropriate? > >>>>>> I'm not confortable relabeling databases with potentially > >>>>>> sensitive data to var_lib_t because mysql was uninstalled. > >>>>>> > >>>>> > >>>>> The argument seems to be for removing the ability to remove > >>>>> modules. > >>>>> It would be the roach motel style of policy management. > >>>>> > >>>> > >>>> I like it, policies check in but don't check out. I > haven't heard > >>>> an argument about 1) how I'm crazy and wrong or 2) how to keep > >>>> systems running as expected otherwise though. > >>> > >>> There's certainly a case for leaving all policy > installed. Policy is > >>> configuration data, which RPM also leaves installed when removing > >>> packages. > >>> We could easily treat policy the same. > >> > >> Our app has 140 rpms that install policy. They install in > the %post > >> and do a restorecon of the relevant installed files and > >> /etc/selinux/mls/modules. Daemons are stopped in the > %preun. Policy > >> is removed in the %postun and more restorecon occurs. The biggest > >> annoyance with this approach is the 140 individual > transactions are > >> ssllooww. > >> > > > > Yes, if you want to test out the patch sent to the rpm list > and report > > results with lots of policy packages that would be awesome :) > > > >> I would really like to see policy batched up and installed > early in > >> the transaction. I think blindly leaving the policy behind on > >> uninstall is configuration management insanity. When an rpm is > >> removed, all of the unmodified installation should be removed with > >> it. Files should be relabeled to match the post > installation policy. > >> That way a subsequent install behaves the way you would > intuitively > >> expect. > >> > > > > I see the claim but I don't see the argument. A subsequent install > > will either replace the old module or do nothing (if its > the same) and > > all the old files will already be labeled properly, in fact this is > > the main reason I want to leave old policies around. Note > that users > > will always be able to remove policies themselves, I just > don't think > > we can make rpm smart enough to know the users intentions > (perhaps if > > it was written in python we could just import psychic :) ) > > We are going to have to disagree on what is proper. Based on > our experience with multiple policies, I think you are going > to get into trouble with policy upgrades when type > declarations move or multiple rpms declare the same type in > policy. You have to think about how policies and rpms evolve > over time. > So renames are a different issue that we are thinking about. Eg., if a module claims to replace a module meaning it provides the same type-space and behavior then we need some facility for telling rpm so it can remove the old and add the new during the same transaction, this is already a work in progress. Removing a policy entirely is what the above thread was about, and I still maintain that automated removal of policies is a bad idea, violates the principle of least surprise and has the potential of leaking sensitive data or leaving the system inconsisten or non-functional. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
