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