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