avc denied from logrotate

[Stephen Smalley]

On Sun, 2004-07-11 at 02:37, Russell Coker wrote:
> On Sat, 10 Jul 2004 16:57, Richard Hally <rhallyx at mindspring.com> 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 at epoch.ncsc.mil>
National Security Agency