[redhat-lspp] Problem with the current cron patch.

[Stephen Smalley]

On Thu, 2006-10-26 at 14:57 -0400, Stephen Smalley wrote:
> On Thu, 2006-10-26 at 10:19 -0400, Daniel J Walsh wrote:
> > The current cron patch attempts to allow users to specify the 
> > role/type/mls context for a particular job to run at.  You simply specify
> > 
> > SELINUX_ROLE_TYPE=staff_u:staff_r:staff_crond_t:SystemLow-s0:c15
> > 
> > in the crontab.
> > 
> > The problem is that users logically think they can specify other 
> > roles/types in the file.  Except the  patch is doing an entrypoint check 
> > on the  cron file.    But the only entrypoints defined in policy look 
> > something like this
> > 
> > allow $1_crond_t  $1_spool_cron_t: file entrypoint;
> > 
> > So if the user specifies,
> > 
> > SELINUX_ROLE_TYPE=staff_u:sysadm_r:sysadm_crond_t:SystemLow-s0:c15
> > or
> > SELINUX_ROLE_TYPE=staff_u:sysadm_r:sysadm_t:SystemLow-s0:c15
> > 
> > The entrypoint check fails and the job is denied.    Now we could allow 
> > users to write a loadable policy module that said something like
> > 
> > allow sysadm_t  staff_spool_cron_t: file entrypoint;
> > 
> > But the cron job will fail, because the crond_t is not allowed to 
> > transition to sysadm_t.  So we could force the user to specify 
> > sysadm_crond_t.  Which might work.
> > 
> > I see this as being too confusing for the  user and would like to change 
> > it so the user can only specify MLS values.
> > 
> > SELINUX_MLS_LEVEL=SystemHigh
> > 
> > And then the old mechanism would run the job as 
> > staff_r:staff_crond_t:SystemHigh.
> > 
> > Thoughts?
> 
> I'm not clear on what the current cron patch does, but I had thought
> that it was going to support multi-context cron by maintaining separate
> cron spool files per context, and the user could e.g. create separate
> crontabs for different roles or levels if they were authorized for more
> than one role or level, and could only create each crontab if running in
> that role or level in the first place (such that the crontab was
> properly labeled with a corresponding type and level).  Not by
> specifying a context in the crontab file itself, except possibly for the
> system cron jobs defined by /etc/crontab et al where one might need such
> specification (just as one specifies the user identity in /etc/crontab
> but not in per-user crontabs).
> 
> If crond allows you to specify arbitrary contexts in the crontab file
> itself, that is obviously not good.

At what point was the approach to cron completely redesigned?  Where was
this described?

The current approach is completely unusable AFAICS, not to mention
unsafe.

-- 
Stephen Smalley
National Security Agency