Not good
Daniel J Walsh
dwalsh at redhat.com
Tue Apr 6 15:01:44 UTC 2004
David Caplan wrote:
> Daniel J Walsh wrote:
>
>> Gene Czarcinski wrote:
>>
>>>
>>> I do believe that the policy packages needs some work:
>>>
>>> 1. Cannot be built in a private build tree (this possibly caused the
>>> "policy." problem which is fixed in 1.9.2-11 ... we will see if it
>>> builds in the private tree by a regular user).
>>>
>>>
>> This is a bug caused by the user being unable to read policy_config_t
>> files (file_context)
>>
>
> I'm not sure I see what the "bug" is here. A "regular user" should
> not be building the policy for a system. A user should be able to
> build a private copy of the policy (eg, for testing, analysis, etc),
> but these files should have regular user file labels (i.e., *not*
> policy_config_t or policy_src_t). Any user/domain should be able to
> run checkpolicy, but much thought and consideration needs to be given
> as to which domains may run checkpolicy in the checkpolicy_t domain.
> Maybe I'm reading too much into this?
>
> David
>
I don't believe that is what the user was complaining about. The
problem is that when you build any rpm, it tries to read
/etc/security/selinux/file_contexts which is marked policy_config_t.
Rpm is storing the file_contexts of files in its headers. The current
policy-1.9.2-12 allows users to read this, problem is that rpm needs to
then check if the security contexts are valid. So they need
can_getsecurity defined. This has been updated for policy-1.9.2-13
(Available on people). This is being governed by the
user_canbe_sysadm tunable. If you turn this off only staff_u would be
able to do it.
Normal users running checkpolicy would still require the can_setenforce
and maybe some other privs.
Dan
More information about the fedora-selinux-list
mailing list