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.
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.
If the app developer is concerned about the post-uninstall type
enforcement on application created files, a separate policy rpm solves
the problem.
joe
--
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.
