The libvirt infrastructure requires the availability of the context files.
In this patch, we add the defaults to the three predefined application
contexts (mls/mcs/standard).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When SELinux user system_u starts crond during system booting up, its
cron job process should be in the system_cronjob_t domain, which has
the required entrypoint permission on system crontab files labeled as
system_cron_spool_t. Otherwise we can run into below error messages:
Jan 31 08:40:53 QtCao crond[535]: (system_u) Unauthorized SELinux context (/etc/crontab)
Jan 31 08:40:53 QtCao crond[535]: (system_u) Unauthorized SELinux context (/etc/cron.d/sysstat)
The weird thing is that the getdefaultcon command even can not fetch
"system_r:cronjob_t:s0" but "system_r:logrotate_t:s0" ! After fixing
default_contexts files the getdefaultcon command could properly fetch
"system_r:system_cronjob_t:s0" :
root@QtCao:/root> getdefaultcon system_u system_u:system_r:crond_t:s0
system_u:system_r:logrotate_t:s0
root@QtCao:/root>
root@QtCao:/root> grep crond_t /etc/selinux/refpolicy-mls/contexts/default_contexts
system_r:crond_t:s0 user_r:cronjob_t:s0 staff_r:cronjob_t:s0 sysadm_r:cronjob_t:s0 system_r:system_cronjob_t:s0 unconfined_r:unconfined_cronjob_t:s0
root@QtCao:/root>
root@QtCao:/root> getdefaultcon system_u system_u:system_r:crond_t:s0
system_u:system_r:system_cronjob_t:s0
root@QtCao:/root>
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
The attached patch adds sepgsql_contexts file into appconfig-*
directory. This configuration is used to initial labeling on
installation time for each database objects.
We can easily look up an appropriate label using selabel_loopup(3)
APIs. The 'sepgsql_contexts' is default for SE-PostgreSQL.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
X Object manager policy revisions to x_contexts.
Many of the specific event, extension, and property types have been
removed for the time being. Polyinstantiation allows selections and
properties to be separated in a different way, and new X server support
for labeling individual extension requests (as opposed to entire extensions)
should make the extension querying problem easier to solve in the future.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Chris PeBenito <cpebenito@tresys.com>
