Testbed Support for GridPP member institutes [mailto:[log in to unmask]] On Behalf Of Mike Jones said:
> I cannot find any suggestion that a VOMS credential should or
> must be a maximum of 24 hours long.
One for Dave or Mingchao ... it certainly used to be the case that the limit was 24 hours and a VO had to ask for a specific exception and justify it. However the general trend of security policy revisions seems to be to make them more vague, so maybe there is no definite statement any more. The argument for a limit is that there's no way to revoke a VOMS credential, and that myproxy and the WMS proxy renewal service mean that a longer lifetime isn't needed for normal uses. (Conversely if longer credentials are now allowed then we could get rid of myproxy and simplify things substantially!)
> (Incidentally document 573348 dictates that VO names must be formatted
> as a RFC 1034 sub-domain name, this isn't current practice for many VOs.)
By the time that policy was established there were a fair number of existing VOs, and renaming a VO is non-trivial so they were allowed an exception. New VOs are supposed to adhere to that convention.
> If credentials with long lifetimes are forbidden by policy at the resources
> or a grid level then this should be defined and enforced at the
> resource(s)'s gateways not at the Attribute Authority.
That's one of many things which have been discussed endlessly but never implemented (likewise restricting proxies to work only on specific sites or services).
> After a series of tests I find that I am wrong in my assumptions about how
> authorisation is effected at resource gateways.
AFAIR the goal of the restrictions was to prevent privilege escalation, e.g. you shouldn't be able to take a standard atlas proxy and turn it into one with a production role. However simply renewing an existing credential isn't escalation and should be allowed. Likewise IMO an expired VOMS attribute should only invalidate itself, it shouldn't say anything about other credentials elsewhere in the chain. However what actually gets implemented is not always in accord with the intention! Usually variations are only noticed when it causes a problem somewhere - e.g. as described in this ticket:
https://ggus.eu/tech/ticket_show.php?ticket=67040
> $ voms-proxy-init -cert /tmp/x509up_u503 -key /tmp/x509up_u503 \
-voms ngs.ac.uk
NB You can use the --noregen option to renew from an existing proxy rather than a cert - useful if you have a long passphrase!
> I am subsequently authenticated as a member of the manchester.ac.uk VO at
> a grid resource which uses LCAS-LCMAPS for Authz and accepts both VOs.
> This is clearly broken as it takes away the control of the user to specify
> under which VO their job is to be run and accounted against.
It depends what you mean by broken. Use of proxies with more than one VOMS credential is certainly broken in the sense that it's largely supported by any of the middleware and behaviour is fairly undefined, but that's missing functionality more than a bug. On the other hand I don't see it as a security issue - why should one VO be able to veto the issue of attributes for a different VO? The usual analogy is that VOMS ACs are like visas in a passport, and you don't generally expect one country to refuse you a visa because you already have one from a different country, let alone because you might have one in the future. Fundamentally, VOMS ACs make positive assertions that you have some rights, not negative assertions that some rights are denied. (AFAIR the original VOMS spec did also have negative assertions, but it was dropped almost immediately because the logic gets highly complicated - e.g. what do you make of a negative assertion in an expired credential?)
Stephen
|