Sorry if I gave a false impression here. It wasn't my intent. No one has
threatened us with disconnection and Mingchao of course 
is only trying to help RAL by alerting us to issue in the database. The
point I was trying to make however was the inevitability of these kind
of detailed dialogues regarding host by host status. Often within a site
there are complex reasons why not patched / false positives etc and of
course the exposure for different kinds of hosts is different and thus
the urgency to fix. A tape server with only root login anyway is clearly
much less urgent to address than a UI with lots of external general
users.

We meet regularly to assess our status wrt patching and the story is
rarely simple - false alarms do happen. To reproduce this internal
dialogue with external parties will would be a pain. However I'm not
necessarily against this activity in principle, I support
open reporting as a way of improving quality and this goes for security
too. However its necessary to get the processes right. 

Regards
Andrew

> -----Original Message-----
> From: Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]]On Behalf Of Gianfranco Sciacca
> Sent: 26 September 2009 12:40
> To: [log in to unmask]
> Subject: Re: recent EGEE policy wrt kernel patching
> 
> 
> Having seen the poster I got the impression the Pakiti 
> development was  
> not in production yet. Perhaps I didn't read it well enough, 
> but since  
> there has been no announcement (I know of) to sites about 
> this type of  
> monitoring, I did by default assume this was part of the "future  
> work". By the way, Mingchao email to the Tier-1 closed with the  
> following:
> 
> "I would like to know whether the above result is correct (might be  
> false
> alarms)."
> 
> so this does not strike me as unreasonable either. It didn't sent a  
> threat of disconnection from what I can see, but obviously I might  
> miss part of the context here.
> 
> Furthermore, from lunchtime and breakfast informal conversations, I  
> got the impression the "cut from the grid" move was an 
> escalation due  
> to the large proportion of sites who did not give feedback to the  
> original request. None of this is official, though, so don't 
> quote me  
> on it. Frankly, the only thing I've found unreasonable so far is the  
> fact that we got two requests via email by Mingchao for sending  
> feedback "before the end of the day". I think that if OSCT sends an  
> advisory asking sites to patch their systems, the request 
> should be of  
> the form: send the request at time X to be satisfied by time Y and  
> give feedback by time Z. With Y-X being a reasonable amount of time  
> and Z-Y  certainly > 7 hours. If we get an EGEE broadcast and 
> then an  
> unrelated number of days later we get a 7-hour deadline to 
> confirm the  
> request was satisfied, it's no surprise perhaps many reply 
> didn't make  
> it at all or some perhaps did not take it all that seriously 
> (well, I  
> for one, took it seriously anyway).
> 
> As for not disclosing patching information by email, well, each site  
> entry in the GOCDB has a listing of Mingchao and his telephone number.
> 
> cheers,
> Gianfranco
> 
> On 25 Sep 2009, at 12:36, Peter Gronbech wrote:
> 
> > This security testing has been talked about for some time and was  
> > run by
> > Romain Wartels group.
> > It basically ran a grid job at your site which did a rpm 
> -qa and then
> > compared that with what was expected for a system running that OS.
> > 
> http://indico.cern.ch/contributionDisplay.py?contribId=107&ses
> sionId=137
> > &confId=55893
> > Shows an abstract and a Poster they presented about it at 
> EGEE09 this
> > week.
> >
> > I must admit I was surprised that they sent the email from 
> the EGEE  
> > PMB
> > saying sites that did not act would be de certified, but I 
> think I'm  
> > in
> > favour generally.
> >
> > I have no doubt that the data stored is being held in a 
> responsible  
> > way.
> >
> > Cheers Pete
> >
> > -- 
> > 
> ----------------------------------------------------------------------
> > Peter Gronbech  Senior Systems Manager and      Tel No. : 
> 01865 273389
> >              SouthGrid Technical Co-ordinator  Fax No. : 
> 01865 273418
> >
> > Department of Particle Physics,
> > University of Oxford,
> > Keble Road, Oxford  OX1 3RH, UK  E-mail : 
> [log in to unmask]
> > 
> ----------------------------------------------------------------------
> >
> > -----Original Message-----
> > From: Testbed Support for GridPP member institutes
> > [mailto:[log in to unmask]] On Behalf Of Sansum, Andrew
> > (STFC,RAL,ESC)
> > Sent: 25 September 2009 11:47
> > To: [log in to unmask]
> > Subject: recent EGEE policy wrt kernel patching
> >
> > Does anyone else have a view on the recent change in EGEE policy wrt
> > security patching? I was suprised (to say the least) to find that  
> > there
> > was a pakiti server somewhere out in EGEE land that was accumalating
> > host level information about heaven only knows what but at 
> a minimum  
> > our
> > kernel versions across our farm. This presumably to be used to make
> > operational decisions about which sites should be cut off from the  
> > Grid.
> >
> > The inevitable outcome has been a dialogue along the lines 
> of "please
> > account for why you are running kernel xxx on host yyy". Am 
> I the only
> > one who finds this very annoying, both in principle (that 
> sites will  
> > be
> > expected to justify their host level configuration to third 
> parties)  
> > and
> > also how it has been implemented in practice _ ie I've just 
> disovered
> > that there is a server somewhere out there holding a lot of 
> sensitive
> > information about our patching status.
> >
> > i don't have any problem in principle with some aspects of 
> this work,
> > but its a question of how it is done.
> >
> > What do others think - I plan to mail the GRIDPP PMB today 
> about this
> > but would like to know if I am in a grumpy minority of 1 or if the
> > feeling is more widespread.
> >
> > I don't have access to the dteam list but understand this hasn't yet
> > been discussed there. Mingchao's email is attached below - 
> I should  
> > say
> > that I'm not trying to shoot the messanger here - my issue 
> is the way
> > this has emerged from EGEE.
> >
> > Regards
> > Andrew
> > = 
> > = 
> > 
> ======================================================================
> > =============
> > Dear Security Contacts (in Bcc) and Tier2 Coordinators,
> >
> > Yesterday (23 September 2009) EGEE PMB (Project Management 
> Board) had
> > made
> > following decision:
> >
> > Any EGEE site that did not FULLY apply the security patches
> > (CVE-2009-2692
> > and CVE-2009-2698) by 30 September 2009 will be 
> DISCONNECTED from EGEE
> > infrastructure.
> >
> > In order to assist GridPP PMB to make an informed decision to comply
> > EGEE
> > PMB's requirement, could ALL GridPP sites please report me your  
> > current
> > patching status of ALL your Grid systems? If your site has not been
> > FULLY
> > patched, please provide me following information:
> >
> > - Full list of un-patched systems;
> > - Reason of not being patched;
> > - Any alternative way to patch your system (e.g. to compile your own
> > kernel/driver);
> > - The consequence if these up-patched systems were turned off;
> > - Risk if these up-patched systems were up and running;
> >
> > ALL sites (including those who have reported me last week) MUST send
> > your
> > report to me (copy it to your T2 coordinators please) by the end of
> > today
> > (24 September 2009).
> >
> > Thanks,
> >
> > Mingchao
> > -- 
> > Scanned by iCritical.
> 
> -- 
> Dr. Gianfranco Sciacca			Tel: +44 (0)20 7679 3044
> Dept of Physics and Astronomy		Internal: 33044
> University College London		D15 - Physics Building
> London WC1E 6BT
> 
> 
> 
>