Re: Added is_context_configurable function

Stephen Smalley wrote:

>On Tue, 2005-01-11 at 17:10, Colin Walters wrote:
>
>
>>I've said this before, but I don't like the idea of having to edit
>>file_contexts whenever I want to change the labels. I feel that the
>>on-disk version should be canonical, and the file_contexts only used for
>>system initialization.
>>
>>
>
>That is also my view. However, if people are going to run setfiles or
>restorecon at runtime to check or set contexts (which is current
>practice in Fedora), then we do need a way to distinguish legitimate
>customizations from what are essentially bugs in the policy (e.g. lack
>of a file type transition rule) or applications (e.g. failure to
>preserve or set context on a file where file type transition rules are
>insufficient). The file contexts configuration seemed like a reasonable
>way to capture that distinction to me. Two questions:
>1) Is it sufficient to identify legitimate customizations based solely
>on the TE type of the file? If not, what other information should be
>taken into account, irrespective of whether this is done via
>file_contexts or via a different config file?
>
>

I think we can somewhat do that now. I am not looking at the ability to put general
files in random location, just based off the wim of the Administrator. IE putting
/var/named some where else is not what we are considering, in this case a secondary
file_context.local file should be required. But the usual case of labeling file for sharing
IE samba_share_t, http*, ftp_anon_t. These will be come common, and the admin should not
be required to update file_context in this case. (We had considered calling them sharables)

>2) Is it feasible for the policy writer to identify all such TE types a
>priori in the policy without covering such a large set as to make
>setfiles/restorecon completely useless by default? If not, what
>mechanism will be provided to allow users/admins to easily mark
>additional types without conflicting with future policy updates?
>
>
>

I believe so as long as we confine it to shareable types of context, not files that have standard locations,
that an admin might decide to change.

--
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.