http://people.fedoraproject.org/~dwalsh/SELinux/F13/kernel_files.patch
New file context
Lots of new interfaces
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.
* need additional explanation as to the purpose of system_conf_t.
* the files_relabel_all_files() change is still rejected, since block
and chr files should have regular file types.
* the the files-delete_isid_type_files() additions need their own
interfaces instead.
* same thing for files_delete_usr_files()
* the files_read_usr_files() change is excessive
* files_search_var_log() is wrong, var_log_t doesn't belong to the files
module. There is already an equivalent interface in logging.
* 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.
* files_create_default_dir() needs to be 2 interfaces.
* I don't even know what to make of files_boot().
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
On Thu, 2010-03-04 at 14:08 -0500, 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
>
[...]
> * the files_relabel_all_files() change is still rejected, since block
> and chr files should have regular file types.
That is, they should *not* have regular file types.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
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.
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
On 03/05/2010 06:12 PM, Daniel J Walsh wrote:
> 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.
>>
Yes, it is related with the s-c-firewall which writes to the sysctl.conf
file (to enable masquerading ) and creates the sysctl.conf.old file. But
s-c-firewall creates also 'iptables.conf.old' under /etc directory.
So we came up with a new type system_conf_t to solve this issue.
>>> * 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?
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100308/ae4bb83b/attachment.html
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