Hi
BTW the jury is still out IMO about both the job monitoring and the L&B
publishing. We've not enabled the latter here because it breaks dutch
law. Yeah I know, but it's the law and I don't feel like getting sued.
If we had a different L&B schema it might make things easier, it's
hard to publish just the info you want without publishing pretty much
everything.
The job monitoring may have much of the same problem, I haven't really
inspected it yet. Secure mode might help a lot, particularly if one
could make it so that the only person who could read a job's published
info was the submitter, unless the submitter gave explicit permission to
others. I suspect this is not what is meant by secure mode though.
JT
Dr D J Colling wrote:
> Hi Steve,
>
>
>>I welcome Kostas's remarks. All I am criticising is the fact that
>>details of specific vulnerabilities are being posted to a huge mailing
>>list. Procedures exist - which he chooses to ignore.
>
>
> In this case he ignored it because Laurence essentially said that there
> was no real danger in running RGMA in an insecure mode. Where there
> clearly is and Kostas wanted to show that Laurence had, inadvertently,
> mis-judged the situation.
>
>
>>>As for this particular problem I think that:
>>>
>>>1. the RGMA test should be made non critical so that sites who wish
>>>to run with such a security hole are welcome to do so but sites that
>>>don't are not forced to. I may be wrong but I believe that this
>>>would only really damage the accounting at the moment and that would
>>>catch when a patched version is available later... am I correct in
>>>this understanding?
>>
>>It depends what the site is doing - there is also the job wrapper
>>publishing and the L&B for those sites that run one. It also depends
>>upon whether you would propose to deploy only a secure connector which
>>would correspond to the final state of the migration.
>
>
> My point is that we shouldn't have a critical test that forces a site to
> introduce a known security hole. If that hole only effected the service
> that had the hole, as Laurence had thought, then to some extent I don't
> care too much, but if it can allow other damage, as Kostas demonstrated,
> then I do care. In this case the decision whether or not to take the risk
> should be with the site and the site should not be penalised (e.g. for not
> delivering the reasources promised) if they decide not to run it ...that
> is it should not be a critical test.
>
> While the job wrapper publishing is very nice I don't know of anybody
> actually using it and I don't believe that anybody is using the L&B
> publishing yet for the reasons that we have discussed before, and so no
> core functionality would be lost if RGMA were *temporarily* turned off at
> a concerned sites.
>
>
>
>>>2. if the RGMA developers were to produce a secure version which was
>>>free from such issues and the deployment group were pushing it for
>>>rapid deployment, it would make a lot of people happier that
>>>security vulnerabilities were being taken seriously by LCG.
>>
>>We can easily provide patches to the code for these issues if this is
>>requested - however we have so far received no such request.
>
>
> And this request would come from vulnerability group?
>
>
>>>It is only when the community feel that vulnerabilities are being
>>>taken seriously that people like Kostas will (consistently) follow
>>>the procedure.
>>
>>In this case no attempt has been made to submit the vulnerability for
>>consideration. The 2 vulnerabilities already submitted against R-GMA
>>have both been followed up.
>
>
> I thought that this was an extention of the existing vulnerability (number
> 10707 ... rated low to medium) to which the "Proposed Solution" made it
> clear that there would be no real soution available for many months let
> alone when (if ever) it would be deployed. This vulnerability was sent to
> the security list last week and is what prompted David and Kostas to see
> what effect it could have... given that running insecure RGMA is a
> critical test! Remember that this is after the 45 days since the
> vulnerability was first notified to the vulnerabilities group. I think
> that what Kostas showed was that this vulnerability was mis-rated at low
> to medium because people had not seen the possible dangers associated with
> it.
>
>
>>Deploying authentication more rapidly could be done - it all depends
>>upon the priority given to it by SA1.
>
>
> Indeed it does and it is SA1 that decides whether or not is critical.
>
> Would authentication protect against these vulnerabilities (at least to
> the level of knowing who had done it when it had been done) or is a full
> implementation of the authorisation required? If moving to the secure RGMA
> would at least partially solve the problem then we should urge SA1 to move
> quickly in this direction. However the general point is that it should not
> be a critical test again until the vulnerability has been fixed at least
> at the level of knowing who the offender is.
>
> We created the vulnerabilities group with the procedures that it has as a
> huge compromise between the different factions so that we could stop
> arguing and actually do something about the vulnerabilities. We now need
> to act on what it finds and if it finds that there will be no solution for
> many months and that may or may not ever be deployed people have to
> consider whether or not they want to run that part of the software. If
> enough people think that a particular security hole is sufficiently
> dangerous that they stop running the software then I suspect that it will
> become fixed quite quickly.
>
> Perhaps once a vulnerability has been sent to the csirts list there should
> be a discussion on that list as to what the full implications are so that
> sites can decide whether or not to keep running the software. This would
> be after the 45 days that the middleware people have already had to fix
> it.
>
> Finally, I would like to say that I am not having a pop at RGMA in
> particular it just happens that this vulnerability was in this particular
> piece of middleware and I look forward to the day when a secure and
> reliable RGMA is providing all our monitoring needs. It is about how we
> deal with vulnerabilities ... we claim to be a production system.
>
> ... sorry for such a long email...
>
>
> All the best,
> david
|