Re: 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(a)mindspring.com&gt; 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(a)epoch.ncsc.mil&gt;
National Security Agency