My previous version had a minor bug in admin_role where it was using cobblerd_var_log_t, and cobblerd_var_lib_t instead of cobbler_var_log_t, and cobbler_var_lib_t.
Whilst i was at it, i decided the implement a cobbler_etc_t for cobbler content in /etc. This because you cannot admin a cobbler environment witouth having access to cobbler config files and i dont want to give cobbler_admin access to manage etc_t.
As a consequence if this i also removed the files_read_etc_files(cobblerd_t), as i think that cobbler only needed it to read its own files in /etc. However this is not confirmed, and it may need read access to etc_t afteral.
Also i would like to underscore my reason for using public_content_rw_t. One of the reasons is that i do not want to give cobbler access to manage httpd_sys_content_rw_t. In general i do not want to depend on apache module at all.
Signed-off-by: Dominick Grift <domg472@gmail.com>
Signed-off-by: Chris PeBenito <pebenito@gentoo.org>
> From my understanding of the FUSE website, the data from the userland FS
> is transferred through this device. Since the data may go up to system
> high, I believe the device should still be system high.
>
Making it systemhigh will generate lots of AVC messages on every login
at X Since fusefs is mounted at ~/.gfs. It will also make it unusable I
believe on an MLS machine. Mostly I have seen fusefs used for remote
access to data. sshfs for example.
Add MLS constraints for several network related access controls including
the new ingress/egress controls and the older Secmark controls. Based on
the following post to the SELinux Reference Policy mailing list:
* http://oss.tresys.com/pipermail/refpolicy/2009-February/000579.html
