Dear all,
In addition to the comments by Martin (which I fully and wholehartedly
support) there are fundamental problems with the following
requirement from the Atlas Wiki:
"Host certificates (non-Globus). These certificates should not be
Globus-style certificates: the DN should not start it 'host/'. When
requesting certificates, remember to ask your CA for SSL web server
certificates (that don't include any string in the beginning of the DN).
e.g. C=CH, O=CERN, OU=GRID, CN=pcatlas265.cern.ch"
This implies that either the site admin takes on the full responsibility
for all actions done with that credential (i.e. when it is abused to
impersonate other systems, or even worse in an agent context when it's used
to access other services), or by giving the keypair to the VO manager it
gets compromised by construction.
Is Atlas (in this case) actually expecting the site to be liable for
the VO's actions??
Also, a compromise of the host credential affects *all* services run
on that machine -- not only the ones for one specific VO, but for all
VOs supported on that box. This is a highly undesirable situation.
What you could be giving out are proxies of the host credential (using,
say, the proxy renewal service software that's currently part of the RB. But
still you are in unchartered territory.
The natural way is for a VO administrator to take responsibility for
the VO services, and thus have these authenticate using a delegated
credential from the responsible person (like the globus "personal
gatekeeper").
DavidG.
Bly, MJ (Martin) wrote:
>
>> -----Original Message----- From: LHC Computer Grid - Rollout
>> [mailto:[log in to unmask]] On Behalf Of Graeme A Stewart
>> Sent: Wednesday, September 14, 2005 9:22 PM To:
>> [log in to unmask] Subject: Re: [LCG-ROLLOUT] VO boxes
>> (was LCG-2_7_0 sooner or later ....) ...... But if you find a ripped
>> movie you can identify the compromised certificate used (you run the
>> gridftp server) to upload it and take appropriate action. How can VOs
>> offer us the same guarantees of accoutability if their box was used for
>> such a nefarious purpose? The implications of a VO software manager's
>> certificate being compromised are quite horrendous. To quote from
>> https://uimon.cern.ch/twiki/bin/view/Atlas/DDMSc3:
>>
>> "The ATLAS Distributed Data Management will install the following set
>> of components in the site VO box. [...] * Claims service and Space
>> Management service - The claims service runs on an apache server [...]
>> It will be contacted from within the VO box and outside via http(s)
>> requests (currently ports 443 and 80).
>>
>> [...]
>>
>> Connectivity
>>
>> * Login as root via ssh/gsi"
>>
>
>
> This is a cookoo-land requirement and is unlikely to be acceptable at any
> site. RAL IT security policy certainly will not allow root access by any
> non-staff (however encyrypted) so it isn't going to happen here.
>
> It is difficult enough trying to keep the bad guys out without the risks
> associated with `outsiders' having any sort of priviledged access to
> hosts.
>
> I'm happy to try and help LCG software do what needs to be done on my
> site but some realisim needs to be instilled in the proposed ways of
> doing things. I can't yet see any lessening in the increasing
> development of monitoring systems that will put more load on the central
> services at a site to provide (duplicated) information (remember the
> pbs/torque job status polling anyone?) and poke more holes in firewalls.
> A cluster isn't any good for batch work if it's spending too much time
> responding to monitoring requests.
>
> It would be nice if the experiments would agree (ha!) on the information
> they need about what's going on and then delevelop a single entity for
> each site that gets *all* the data in the approved grid fashion and
> publishes it in the approved grid fashion. We'd then only need one and
> could control it and possibly trust it. Now I realise that's probably
> also a cookoo-land wish but then the grid looks increasingly
> cookoo-landish from some angles.
>
> Martin Bly, RAL Tier1 Systems Team.
--
David Groep
** National Institute for Nuclear and High Energy Physics, PDP/Grid group **
** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **
|