[redhat-lspp] Some where along the line it was pulled off the list.

[Klaus Weidner]

On Thu, Oct 26, 2006 at 03:33:09PM -0400, Daniel J Walsh wrote:
> On Tue, 2006-07-25 at 12:42 -0400, Janak Desai wrote:
> >Also copying Klaus, so he can give us an evaluation perspective.
> >On Tue, 2006-07-25 at 12:02 -0400, Jason Vas Dias wrote:
> >> On Tuesday 25 July 2006 11:46, Janak Desai <janak at us.ibm.com> wrote:

> >> >  crontab wouldn't have to do anything. When a user logs in at
> >> >  SystemLow, a /var/spool/cron-at-SystemLow directory will be bind
> >> >  mounted on /var/spool/cron. When the user changes level to
> >> >  SystemHigh, newrole will unmount /var/spool/cron-at-SystemLow and
> >> >  bind mount /var/spool/cron-at-SystemHigh. So basically you will
> >> >  end up with different cron job files for different security
> >> >  contexts. 
> >>
> >> This is crazy! 
> >> 
> >> Please remember that the /var/spool/cron directory is for MULTIPLE
> >> USERS - ie. many different users, potentially all at different
> >> levels, will need to access /var/spool/cron files. 
> >
> >Yes. I was just explaining polyinstantiation of /var/spool/cron.  As
> >far as multiple users, the polyinstantiation mechanism takes care of
> >that by giving users private namespaces. 

Multiple /var/spool/cron/ directories would be a very invasive change -
if going that route, it would probably be easier to use special filenames
(such as "/var/spool/cron/jdoe:s1") to indicate the MLS level (or
optionally also user class, type and role). Cron should then verify that
the actual MLS level of the file matches the filename, and execute the
job in an appropriate context.

> >> >  hmm. So you mean we require that crontab creation/edit be
> >> >  restricted to just one level and the user can put the desired
> >> >  context while they edit.  Basically, instead of doing a newrole
> >> >  and then executing crontab, they can just put the desired context
> >> >  (that they would have used in newrole) in the SELINUX_ROLE_TYPE=
> >> >  argument. I think that could work. However, we will need to check
> >> >  with the evaluator that it's ok for SystemLow process to view
> >> >  crontab jobs that are at higher level.
> >> 
> >> As this is the SAME USER doing the editing (root in the case of
> >> /etc/cron.d files, a single user per file in the case of
> >> /var/spool/cron files) what harm could there be in letting the same
> >> user see cron jobs they've created to run in different contexts ?
> >
> >Well, unfortunately some of the MLS/LSPP requirements are not
> >completely logical. 

>From an MLS/LSPP point of view, it's ok if a low user can see job
commands that are intended to be run at a high level, as long as those
job commands are entered and edited at the low level. It would not be ok
if the user edits the crontab at the high level, and the added data would
then be visible for a low user viewing the crontab.

Running jobs at higher levels is fine according to Bell/LaPadula (it's a
"write up" operation), but it may be a bad idea due to integrity
concerns. LSPP isn't concerned about integrity though.

> >> >  We will need  some more work in crontab, which will now have to
> >> >  check that the cron job is being created at low end of the user
> >> >  range. That is, we have to prevent a user, with a range of
> >> >  SystemLow-SystemHigh, from logging in at SystemLow, changing
> >> >  level to SystemHigh and then execing crontab.
> >>
> >> Why ?
> >
> >Because when the first time the user happens to execute crontab, if he
> >is at SystemHigh, the the crontab file will be created at SystemHigh.
> >Then he won't be able to see/edit that file from a lower level.
> >Essentially to edit the crontab file, the user will have to newrole to
> >whatever level that he was in when he executed crontab for the first
> >time. 

If the trusted programs involved are careful with the MLS overrides,
there would be no risk of information leaks (only things not working).
For example, a SystemHigh user can see the SystemLow-created crontab file
and could load it into an editor, but would not be permitted to write to
it. Conversely, the MLS constraints should prevent a low user from
reading a high crontab.

> >> /var/spool/cron files can only be viewed / edited by the user that
> >> created them or root . If they choose to create a crontab at a high
> >> security level, then they should know they need to change into that
> >> level to view / edit the crontab.  
> >> 
> >> This whole feature is of only theoretical or no interest to 99.9999%
> >> of cron users. 
> >> 
> >> We've now given users the ability to run jobs at different contexts
> >> in the same crontab - unless there is a reproducible problem with
> >> the implementation, which I would fix ASAP, I'd against adding any
> >> further functionality to this feature, which is just ending up
> >> making cron more complex with very little gain to most cron users.

Aside from the integrity concerns (which are beyond the scope of
MLS/LSPP), the implementation using a special variable would sound
acceptable for LSPP compliance, assuming of course that it's implemented
correctly.

-Klaus