On Sun, 2004-07-11 at 02:37, Russell Coker wrote:
> On Sat, 10 Jul 2004 16:57, Richard Hally <rhallyx@xxxxxxxxxxxxxx> wrote:
> > Jul 10 02:44:08 new2 richard: now doing logrotate
> > Jul 10 02:44:16 new2 kernel: audit(1089441856.765:0): avc: denied {
> > transition } for pid=4105 exe=/bin/bash path=/etc/rc.d/init.d/cups
> > dev=hda2 ino=864571 scontext=root:sysadm_r:logrotate_t
> > tcontext=root:system_r:initrc_t tclass=process
>
> The role sysadm_r is not permitted to have domain initrc_t. The options for
> solving this are 1:
> role sysadm_r types initrc_t;
> 2:
> role_transition sysadm_r initrc_exec_t system_r;
> domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t)
> 3:
> role_transition sysadm_r logrotate_exec_t system_r;
>
> In option 2 the domain_auto_trans() is needed to prevent the
> command /etc/init.d/whatever from ending up in the context
> root:system_r:sysadm_t which is not a valid context.
>
> The problem with option 1 is that initrc_t then launches other domains so it
> doesn't work.
>
> Steve, what do you think about option 2 vs option 3?
The policy is already set up for sysadm_r:logrotate_t to transition to
system_r:initrc_t upon executing init scripts; logrotate.te includes
domain_auto_trans(logrotate_t, initrc_exec_t, initrc_t), and initrc.te
includes role_transition sysadm_r initrc_exec_t system_r;. The only
item missing is that logrotate_t needs the priv_system_role attribute
for the corresponding constraint. That is all that needs to be changed.
> > Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied {
> > read } for pid=4123 exe=/usr/bin/id name=config dev=hda2 ino=914871
> > scontext=root:system_r:cupsd_t
> > tcontext=system_u:object_r:selinux_config_t tclass=file
>
> Maybe we should change id to read /proc/self/attr/current directly? We don't
> want to have to put in allow or dontaudit rules for every shell script that
> runs "id".
libselinux attempts to read /etc/selinux/config upon initialization, but
only truly needs access if the program will ultimately need a path to a
policy file (either directly or due to a call to a libselinux function
that reads a policy file). I don't think id falls into this category,
so you can just dontaudit the permission.
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
