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&sessionId=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
|
