[redhat-lspp] Some where along the line it was pulled off the list.
Daniel J Walsh
dwalsh at redhat.com
Thu Oct 26 19:33:09 UTC 2006
-------- Original Message --------
Subject: Re: an issue with the cron patch ..
Date: Tue, 25 Jul 2006 12:44:43 -0400
From: Janak Desai <janak at us.ibm.com>
Reply-To: janak at us.ibm.com
To: jvdias at redhat.com
CC: Daniel J Walsh <dwalsh at redhat.com>, sgrubb at redhat.com,
ltcgcw at us.ibm.com, klaus at atsec.com
References: <1153796254.5468.17.camel at localhost.localdomain>
<200607251115.03593.jvdias at redhat.com>
<1153842413.7934.42.camel at localhost.localdomain>
<200607251202.51439.jvdias at redhat.com>
<1153845764.7934.57.camel at localhost.localdomain>
Forgot to copy Klaus.
On Tue, 2006-07-25 at 12:42 -0400, Janak Desai wrote:
> 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 <janak at us.ibm.com> wrote:
> > > On Tue, 2006-07-25 at 11:15 -0400, Jason Vas Dias wrote:
> > > > On Tuesday 25 July 2006 10:53, Daniel J Walsh <dwalsh at redhat.com> 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
>
More information about the redhat-lspp
mailing list