Hi all,
My original message wasn't to be sent to the list, but it finally
managed to get there anyway, but didn't passed through the
translation module of course :-)
Well, I see it has been understood very fine anyway.
Sorry for the mess and thanks for your answers!!
For sure, every known security hole must be fixed or at least
closely watched until the fix arrives. It was just to say that if hole Q
and hole S allow the same kind of exploit, arranging one only
won't close the door for the other one.
I'm very pleased to know that both are considered.
BTW, I recalled from a gLite installation tutorial that the gLite jobmanager
no longer uses the fork jobmanager does it ? I wanted to submit
some job to the CE and not to the WN and I didn't manage
using globus-job-run -q fork so is there another way to do the same
with gLite or has this opportunity/bug been discarded ?
Cheers
David
On Tuesday 15 November 2005 17:42, you wrote:
> David WEISSENBACH a écrit :
> >Salut Eric,
> >
> >Je me spose la question suivante en lisant ce thread :
> >De toutes facons, un utilisateur qcq peut toujours dans
> >son job lancer autant de process qu'il vaut sur le CE via
> >SSH vue la configuration dudit CE (en conséquence a fortiori
> >comme dit)
> >
> >Alors pourquoi le jobmanager fork fait il tant de vagues ?
>
> Well...
>
> it's not because their are _other_ security holes that
> you should accept this one :o)
> In addition ssh daemon on the CE can be tuned by the
> sysadmin. In the case of "fork" jobs it depends on
> the LCG features. Not the same level of configuration
> (and by the way not the same security integration
> at the devel. level :o).
>
> >A+
> >David
> >
> >On Tuesday 15 November 2005 17:06, you wrote:
> >>Hi
> >>
> >>Dr D J Colling wrote:
> >>>Hi Dave,
> >>>
> >>>I do see your point.
> >>>
> >>>Just a couple of points.
> >>>
> >>>1. Of course anybody could perform the DoS attack you suggest, but you
> >>>would know who they were as their DN would be logged as they would have
> >>>gone through the same level of security as anybody running in the batch
> >>>queue.
> >>
> >>Not really, somebody running a job on a WN ( via batch queue) can only
> >>overload the WN, if somebody overload the gatekeeper, all the grid node
> >>shutdown.
> >>The level of security inside the hosts which provide the grids services
> >>have to be higher
> >>
> >>Eric
> >>
> >>>2. It is avery useful debugging tool and that should not be under
> >>>estimated.
> >>>
> >>>All the best,
> >>>david
> >>>
> >>>On Tue, 15 Nov 2005, David McBride wrote:
> >>>>Alessandra Forti wrote:
> >>>>>for me fork manager is a useful tool for who has to debug a possible
> >>>>>misconfiguration from remote. You might not need it but I don't think
> >>>>> we should get rid of it in general.
> >>>>
> >>>>That may well be the case, and I appreciate that you would try to use
> >>>>this facility responsibly -- but I consider this an enormous security
> >>>>risk.
> >>>>
> >>>>As it currently stands, any LCG user can run any abitrary executable
> >>>>they want on my CE -- hundreds of instances at once, if they so desired
> >>>>-- and DoS it into oblivion. Without accounting, without queueing, and
> >>>>without any of the safeguards implemented on my worker nodes, any Grid
> >>>>user can fork as many processes that they want on my gatekeeper and do
> >>>>lots of bad things.
> >>>>
> >>>>This is clearly a BUG, not a feature, and _MUST_ be disabled.
> >>>>
> >>>>Dissentions?
> >>>>
> >>>>Cheers,
> >>>>David
|