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

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency