From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] kernel_files.patch
Date: Fri, 05 Mar 2010 11:46:53 -0500 [thread overview]
Message-ID: <4B91357D.6060001@redhat.com> (raw)
In-Reply-To: <1267729686.11679.58.camel@gorn.columbia.tresys.com>
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.
next prev parent reply other threads:[~2010-03-05 16:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-23 22:21 [refpolicy] kernel_files.patch Daniel J Walsh
2010-03-04 19:08 ` Christopher J. PeBenito
2010-03-04 19:17 ` Christopher J. PeBenito
2010-03-05 16:46 ` Daniel J Walsh [this message]
2010-03-05 17:12 ` Daniel J Walsh
2010-03-08 11:26 ` Miroslav Grepl
2010-03-08 14:02 ` Christopher J. PeBenito
-- strict thread matches above, loose matches on Subject: below --
2010-08-26 22:47 Daniel J Walsh
2010-06-02 20:22 Daniel J Walsh
2010-06-09 13:09 ` Christopher J. PeBenito
2010-06-09 19:10 ` Daniel J Walsh
2009-11-12 21:01 Daniel J Walsh
2009-11-24 13:49 ` Christopher J. PeBenito
2009-05-21 15:24 Daniel J Walsh
2009-03-04 21:24 Daniel J Walsh
2008-11-25 22:00 Daniel J Walsh
2008-12-02 22:51 ` Christopher J. PeBenito
2008-12-03 15:39 ` Daniel J Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B91357D.6060001@redhat.com \
--to=dwalsh@redhat.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.