From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 08 Mar 2010 09:02:10 -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: <1268056930.4155.16.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 2010-03-05 at 11:46 -0500, 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

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

The only reason I can think of is to separate kernel sources out from
usr_t.  Domains that can write to usr_t shouldn't necessarily be able to
write to the kernel sources.

> > * 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_manage_root_files().

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150