Antun, Stephen et al,
> problems. IANAVE, but I feel that this should be somehow addressed; otherwise
> a considerable security risk is neglected.
(I added the MWSG in CC for possible comments)
(Stephen, feel free to propose your improvements to them)
> It seems that the root of all evil lies in grid-proxies that can be created
> with lifetimes limited just by the validity of user's certificate.
More generally, I think ultimately we are/will be limited by our model itself,
which partially puts the management of the credentials in the hands of the users.
Regards,
Romain.
(may not be able to reply, leaving now for a week)
Antun Balaz wrote:
> Hi Romain and *,
>
> First I would like to point that many Grid users avoid voms-proxies just for
> the fact that they cannot made them last for a very, very long time. Having
> that in mind, the following is worrying: as was just demonstrated on the list,
> VOMS AC restrictions can be easily avoided, and voms attributes added as long
> as the stolen grid-proxy is valid (or regenerated if the basic, non-voms part
> of the voms-proxy is valid). So, although the life of an impostor is made a
> little bit more difficult by imposing restrictions on the lifetimes of VOMS AC
> (he/she has to regularly regenerate voms attributes), really there are no
> problems. IANAVE, but I feel that this should be somehow addressed; otherwise
> a considerable security risk is neglected.
>
> It seems that the root of all evil lies in grid-proxies that can be created
> with lifetimes limited just by the validity of user's certificate. Although
> this cannot be changed (one does not have to use grid-proxy-init in order to
> create a proxy!), there is another approach: all grid components may be
> changed so as to NOT accept proxies of any type with lifetime longer than,
> say, 24 hours. That way, there will be no point in creating proxies with
> longer lifetimes, and MyProxy would be used for a proper proxy renewal.
>
> I think we don't have to wait first serious cases of abuse until this is
> streamlined :(
>
> Best regards, Antun
>
>
> -----
> Antun Balaz
> Research Assistant
> E-mail: [log in to unmask]
> Web: http://scl.phy.bg.ac.yu/
>
> Phone: +381 11 3713152
> Fax: +381 11 3162190
>
> Scientific Computing Laboratory
> Institute of Physics, Belgrade, Serbia
> -----
>
> ---------- Original Message -----------
> From: Romain Wartel <[log in to unmask]>
> To: [log in to unmask]
> Sent: Thu, 26 Jul 2007 15:38:15 +0200
> Subject: Re: [LCG-ROLLOUT] Expiration time of a proxy before the end of job.
>
>> Antun,
>>
>> Just one more comment;
>> Additional restrictions to request VOMS AC would help in a useful in
>> some attack scenarios, but I am not a VOMS expert (IANAVE) and I
>> don't know what can reasonably be expected in terms of improvements.
>>
>> Even though a user with a valid proxy may request a VOMS AC at any
>> given time as long as his (standard) proxy is valid, an important
>> feature provided by VOMS is the ability to block compromised
>> credentials at all the VOMS-aware service within the lifetime of the
>> VOMS proxy - hence it is important to maintain a relatively short
>> VOMS AC lifetime.
>>
>> Regards,
>> Romain.
>>
>> Antun Balaz wrote:
>>>> If you steal a proxy you only have the private key for the final
>>>> cert in the chain, so you have to present the whole chain to prove
>>>> your right to the DN. The ACs are embedded in the cert so you can't
>>>> remove (or alter) them without invalidating the proxy.
>>> Thanks for the explanation - then this is indeed the possible way of dealing
>>> with this problem...
>>>
>>> Regards, Antun
>>>
>>>
>>>> Stephen
>>> ------- End of Original Message -------
>> [..]
>> Antun Balaz wrote:
>> > Yes, indeed - I tried it like you did, and it worked. I tried it
>> also with the > help of another user (who had his own .globus in the
>> home directory > unchanged), and it also worked... Probably the
>> environment is different for > root, so it did not work the first
>> time I tried. > > In my view, this is a serious security flaw, and
>> something has to be done - > the addition of voms attributes must be
>> challenged somehow! Romain, what OSCT > has to say? > > Of course,
>> the abuser here would have to rely on the fact that the user has to
>>> create long-lived proxy (grid- or voms- alike). If that is not the
>> case, the > problem is minimized and confined to up to 24 hours. And
>> if the user cannot > create voms-proxy with the lifetime of voms
>> attributes longer than 24 hours, > then he/she would not have much
>> reasons to create the basic proxy part with > longer lifetime... > >
>> Best regards, Antun
>>
>> --
>> Romain Wartel [log in to unmask]
>> EGEE Operational Security Coordination Team
>> C.E.R.N. http://www.cern.ch/LCG
>> Information Technology Division http://www.eu-egee.org/security
>> Bat.28-1-012 http://cern.ch/security
>> CH-1211 Geneva 23, Switzerland
> ------- End of Original Message -------
--
Romain Wartel [log in to unmask]
EGEE Operational Security Coordination Team
C.E.R.N. http://www.cern.ch/LCG
Information Technology Division http://www.eu-egee.org/security
Bat.28-1-012 http://cern.ch/security
CH-1211 Geneva 23, Switzerland
|