From: dwalsh@redhat.com (Daniel J Walsh)
Date: Fri, 05 Mar 2010 12:12:05 -0500
Subject: [refpolicy] kernel_files.patch
In-Reply-To: <4B91357D.6060001@redhat.com>
References: <4B8454CC.4030206@redhat.com>	<1267729686.11679.58.camel@gorn.columbia.tresys.com>
	<4B91357D.6060001@redhat.com>
Message-ID: <4B913B65.4060407@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 03/05/2010 11:46 AM, Daniel J Walsh wrote:
> On 03/04/2010 02:08 PM, Christopher J. PeBenito wrote:
>    
>> On Tue, 2010-02-23 at 17:21 -0500, Daniel J Walsh wrote:
>>
>>      
>>> http://people.fedoraproject.org/~dwalsh/SELinux/F13/kernel_files.patch
>>>
>>> New file context
>>>
>>> Lots of new interfaces
>>>
>>>        
>> * need explanation as to why boot_t would be a device node.
>>
>>      
> I can't find why.  Might be some bizarro ia64 type machine.  I will
> remove and see if it comes back
>    
>> * need additional explanation as to the purpose of system_conf_t.
>>
>>      
> Miroslav has this one.  It has to do with system-config-firewall.
>
>    
>> * the files_relabel_all_files() change is still rejected, since block
>> and chr files should have regular file types.
>>
>>      
> This one comes about because of mkinitd being run by rpm in post installs.
> Which does not happen any longer but I do not see what the benifit of
> turning this off.
> We have several tools like mock, liveusb_creator, kernel make etc that
> are going to create blk_files
> and chr_files in places like /tmp that might run a cp -p or some other
> tool that is going to try to relabel.
>
>    
>> * the the files-delete_isid_type_files() additions need their own
>> interfaces instead.
>>
>>      
> Fixed
>    
>> * same thing for files_delete_usr_files()
>>
>>      
> Removed
>    
>> * the files_read_usr_files() change is excessive
>>
>>      
> Ok can we remove src_t altogether then.  It just seems to cause bugs and
> I see no reason for this label.
>
> It's only reason for being is to create AVC messages.
> ./policy/modules/services/networkmanager.te:files_read_usr_src_files(NetworkManager_t)
> ./policy/modules/services/virt.te:files_read_usr_src_files(virtd_t)
> ./policy/modules/system/userdomain.if:
> files_read_usr_src_files($1_usertype)
> ./policy/modules/system/userdomain.if:    files_exec_usr_src_files($1_t)
> ./policy/modules/system/modutils.te:files_read_usr_src_files(depmod_t)
> ./policy/modules/system/modutils.te:
> files_getattr_usr_src_files(update_modules_t)
> ./policy/modules/kernel/files.if:    files_read_usr_src_files($1)
> ./policy/modules/kernel/files.if:interface(`files_getattr_usr_src_files',`
> ./policy/modules/kernel/files.if:interface(`files_read_usr_src_files',`
> ./policy/modules/kernel/files.if:interface(`files_exec_usr_src_files',`
> ./policy/modules/admin/bootloader.te:files_read_usr_src_files(bootloader_t)
> ./policy/modules/admin/portage.if:    files_exec_usr_src_files($1)
>
> Only one of these you might care about is portage.if,  if that is the
> case then I will eliminate the label from RedHat labeling.
>
>    
>> * files_search_var_log() is wrong, var_log_t doesn't belong to the files
>> module.  There is already an equivalent interface in logging.
>>
>>      
> Removed
>    
>> * the concept of files_dump_core() is wrong.  Applications do core dumps
>> in the current directory, and services just happen to "cd /" at the
>> start.  It doesn't make sense for other domains.
>>
>>      
> Fine I need a domain for creating files in the / directory which I can
> then allow daemon to do.
> Do you want to call this files_manage_root?
>
>    
>> * files_create_default_dir() needs to be 2 interfaces.
>>
>>      
> Added files_root_filetrans_default
>    
>> * I don't even know what to make of files_boot().
>>
>>
>>      
> I think this is caused by early boot of the kernel, /dev/ gets labeled
> boot_t until it gets relabeled in the initrc scripts.  Might not exist
> any longer with the move to dracut.
>
> I will remove and see what happens.
>
> Most people run an unconfined_domain(kernel_t) anyways.
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>    
Is this more to your liking?
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kernel_files.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20100305/da553dc2/attachment-0001.pl