On 07/13/2009 02:52 PM, Joshua Brindle wrote:
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.
One Idea I had was to have two policies. One for install and one for
uninstall, the uninstall policy takes all of the types defined in the
install and typealias them to some base name.
httpd_exec_t == bin_t
httpd_var_run_t == var_run_t
...
--
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.
