Alessandra, this looks a good walkthrough. For a more recent document on
User Registration, see today's GDB agenda.
John
> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Alessandra Forti
> Sent: 08 February 2005 19:29
> To: [log in to unmask]
> Subject: Re: your mail
>
> Hi,
>
> this would also help also to write the security pages for gridpp and
> egee. I have a skeleton for them and started to fill it, but certainly
any
> suggestion to make them better will be really useful. You can find
them
> at:
>
> http://www.gridpp.ac.uk/deployment/security
>
> cheers
> alessandra
>
>
>
>
>
> On Tue, 8 Feb 2005, Dr D J Colling wrote:
>
> > 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
> >>
> >>
> >
>
> --
> ********************************************
> * Dr Alessandra Forti *
> * Technical Coordinator - NorthGrid Tier2 *
> * http://www.hep.man.ac.uk/u/aforti *
> ********************************************
|