Sounds good to me. With ammunition like this I can push for this to be
taken seriously. 

> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Dr D J Colling
> Sent: 08 February 2005 14:31
> To: [log in to unmask]
> Subject: Re: your mail
> 
> Hi John,
> 
> Kostas is making some valid points here. There are clearly security
holes
> in the current setup. Many of these are in the default configuration
> rather than being fundemental to the model and it appears that apart
from
> the odd comment from the odd comment here and there from Stephen Burke
> nobody is looking for these. One of the reasons that Kostas is looking
at
> this is because I am trying to persuade him that we should make all
our
> resources available of the LCG in a unified way.
> 
> What I suggest that Kostas and others do is to find these holes in a
> systematic way. Describe them. Try them at a few (UK) sites in a
> non-hostile way (where possible)  to make sure that they are real.. I
take
> it that people in the UK would not have a problem with this. Then post
> them to this list & rollout and report them to savannah.So something
like:
> 
> Description of problem.
> -----------------------
> 
> Possible vulnerability
> ----------------------
> (i.e. how much access it would allow)
> 
> Where is it a problem [some sites/all sites/no sites]
> ---------------------
> (clearly not a list of actual sites)
> 
> 
> What are the possible solutions
> --------------------------------
> (not including removing all machines from
> the LCG)
> 
> 
> This would be a significant contribution to running this safely.
> 
> All the best,
> david
> 
> 
> 
> On Tue, 8 Feb 2005, Gordon, JC (John) wrote:
> 
> > Kostas, can I suggest that if you have such serious security doubts
that
> > you talk to the experts who are probably not on this list. Security
> > experts from the NRENs and all big HEP labs have been meeting for at
> > least the last 5 years to discuss such issues. If despite this you
feel
> > that 'there is probably some way to subvert the security model' then
the
> > sysadmins on this are not going to be able to reassure you. I
suggest
> > you talk to Dave Kelsey who coordinates security for LCG, represents
the
> > operation area in EGEE security, and is a member of the PMA (the
> > international collaboration of CAs).
> >
> > If he can't reassure you then you should talk to the various Daves
at
> > Imperial about Imperial's future participation in the Grid.
> >
> > JOhn
> >
> >> -----Original Message-----
> >> From: Testbed Support for GridPP member institutes [mailto:TB-
> >> [log in to unmask]] On Behalf Of Kostas Georgiou
> >> Sent: 08 February 2005 10:41
> >> To: [log in to unmask]
> >> Subject: Re: your mail
> >>
> >> On Mon, Feb 07, 2005 at 06:04:59PM -0000, Burke, S (Stephen) wrote:
> >>
> >>> Testbed Support for GridPP member institutes
> >>>> [mailto:[log in to unmask]] On Behalf Of Kostas Georgiou
> > said:
> >>>> The restricted proxy allows you to copy files around though right
> > ?
> >>>
> >>> Yes, but this thread got started with a sysadmin asking about a
job
> >>> running on his system, and you asking how you know who really
> > started
> >>> the job. Assuming that admin knows his own system hasn't been
hacked
> > (in
> >>> which case all bets are probably off) it would have taken a full
> > proxy
> >>> to start the job.
> >>
> >> Are you sure that by using the limited proxy you can't get a full
one?
> >> A combination of gsiftp|ssh|cron that are open now suggests
otherwise
> >> to me and i am sure if i tried i could find a few more ways.
> >> I still believe that you can't know who started the job because of
the
> >> security state of the system. We are lucky that the system hasn't
been
> >> abused yet who know what will happen in the future ?
> >>
> >>>> For the UI you only need access as the user that sumbited the
> >>>> job.
> >>>
> >>> That's true, but it's also pretty much true of computer security
in
> >>> general, whatever someone does they could always claim that
someone
> > else
> >>> had cracked their account. Indeed, someone who was doing something
> >>> nefarious would probably make sure that e.g. they had their
password
> > on
> >>> a post-it note and/or used their birthday, then they have
plausible
> >>> deniability!
> >>
> >> Thats not the same, users are responsible for the passwords (or
their
> >> certs)
> >> but when the system fails to protect the password|cert because of
bad
> >> design
> >> or an administrators fault then you can't blame the user.
> >>
> >>>   If you're broadening this to security in general then indeed we
> > are
> >>> not all that secure, and we've known that for a long time, but it
> > seems
> >>> that no-one has much interest in doing anything about it. Probably
> > it
> >>> will stay like that until we have an incident ...
> >>
> >> True, i wonder if it will be even possible at that time to fix the
> >> problems
> >> without major refactoring. Adding security in a system as an after
> > thought
> >> is a bad idea and in most cases it doesn't work (look at Windows).
> >>
> >> Cheers,
> >> Kostas
> >
> >