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
|