Also copying Klaus, so he can give us an evaluation perspective.
-Janak
On Tue, 2006-07-25 at 12:02 -0400, Jason Vas Dias wrote:
> On Tuesday 25 July 2006 11:46, Janak Desai <[EMAIL PROTECTED]> wrote:
> > On Tue, 2006-07-25 at 11:15 -0400, Jason Vas Dias wrote:
> > > On Tuesday 25 July 2006 10:53, Daniel J Walsh <[EMAIL PROTECTED]> wrote:
> > > > Janak Desai wrote:
> > > > > On Tue, 2006-07-25 at 10:23 -0400, Daniel J Walsh wrote:
> > > > >
> > > > >> Janak Desai wrote:
> > > > >>
> > > > >>> On Tue, 2006-07-25 at 08:32 -0400, Daniel J Walsh wrote:
> > > > >>>
> > > > >>>
> > > > >>>> Janak Desai wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>> Resending to everyone because I had a typo in Jason's address.
> > > > >>>>>
> > > > >>>>> -Janak
> > > > >>>>>
> > > > >>>>> On Mon, 2006-07-24 at 22:57 -0400, Janak Desai wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> Hi Jason,
> > > > >>>>>>
> > > > >>>>>> I have been reviewing and testing the cron patch. As I tried
> > > > >>>>>> using different levels, I came across an issue which I
> > > > >>>>>> should have thought of when we chatted on irc. The problem
> > > > >>>>>> with storing the context in the cron job comes from the fact
> > > > >>>>>> that a user logging in (or newrole'ing) at different
> > > > >>>>>> sensitivity level will need to write to the same file. Even
> > > > >>>>>> if you give powerful mls override privileges to crontab,
> > > > >>>>>> there will still be an issue that useres will be able to
> > > > >>>>>> write something from SystemHigh level that they will be
> > > > >>>>>> able to read from a lower level. Any thoughts on how to
> > > > >>>>>> work around this?
> > > > >>>>>>
> > > > >>>>>> -Janak
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>> Won't the crontab still get created at SystemHigh, so why would
> > > > >>>> SystemLow be able to read it?
> > > > >>>>
> > > > >>>>
> > > > >>> Yes, if it is at SystemHigh then a SystemLow process won't be
> > > > >>> able to read it directly. However, when a SystemLow process
> > > > >>> execs crontab with option -e or -l, it will be to edit/view it.
> > > > >>>
> > > > >>> -Janak
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >> It should not be able to. crontab does not have MLSOverride privs.
> > > > >>
> > > > >>
> > > > >
> > > > > Then how can a user create cron jobs at different levels? For
> > > > > example, lets say a user logs in at SystemLow, creates a cron
> > > > > job (which will create the cron file at SystemLow) and then
> > > > > newroles to SystemHigh. Now he/she won't be able to create
> > > > > a cron job because the SystemHigh process won't be able to
> > > > > edit the cron file, which is at SystemLow.
> > > > >
> > > > > Without MSLOverride, a user won't be able to create jobs at
> > > > > different levels and with MLSOverride we have an information
> > > > > flow problem.
> > > > >
> > > > > -Janak
> > > > >
> > > > >
> > > > Yes another reason why I hate MLS :^).
> > > >
> > > > I guess you need polyinstatiation.
> > > >
> > > > Dan
> > > >
> > >
> > > Please explain what 'polyinstatiation' would mean in terms of crontab -
> > > what should crontab be doing ?
> > >
> >
> > 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.
> > Of course, this will require that the cron daemon will have to
> > walk these /var/spool/cron-at-different-levels directory to
> > process jobs at different contexts/levels.
> >
> No way!
>
Ok :-). Again, I was just explaining what it would take to
polyinstantiate /var/spool/cron.
> > > It would seem to me the problem could easily be overcome by editing the
> > > file at whatever privilege the crontab file allows - then the user could
> > > put whatever role they like in the SELINUX_ROLE_TYPE= variable setting.
> > >
> >
> > 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.
> > 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.
> /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.
>
> Regards,
> Jason Vas Dias
