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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
