Re: [RFC] Install SELinux policies from rpm package header

[Daniel J Walsh <dwalsh@redhat.com>]

On 07/13/2009 02:52 PM, Joshua Brindle wrote:
>> From: Joe Nall [mailto:joe@nall.com]
>>
>> 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@tresys.com>  wrote:
>>>>>
>>>>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>>>>>>>
>>>>>>>> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.