 |
 |
A quick note on the process for resolving this. The issue is currently with the EGI SVG (security vulnerability group). Their job is to assign a severity to the issue and draft an advisory. This will happen during the next couple of weeks, after which the advisory will be published and EGI sites given a timescale (dependent upon the severity) to comply. From the WLCG side I think we have to decide on our preferred solution and work with the SVG to have this reflected in the advisory. We also have to be ready for the changes (eg are DN-less records processed properly today??). This can be done through standard WLCG ops channels. One xrootd question though, as Andy is on the thread. If an xrootd installation is configured not to publish the DN, is anything else suppressed? VO for instance? Oliver. On 02/09/14 09:08, Andrew Hanushevsky wrote: > Hi Oliver, > > Totally understandable. Encrypting the dDN would require a substantial > infrastructure addition to maintain encryption keys. So, it's easier to > just not transmit the DN (a config option). The dashboard doesn't care > but other people would like to know who is causing problems (if any). > Typical case of conflicting requirements. As an aside, wouldn't > unencrypted DN's be available via the public key portion of the > infrastructure anyway? I suppose that doesn't matter if this is a > specific privacy issue but then we shouldn't be transmitting DN's in an > operational context in the first place (encrypted or not). > > Andy > > On Mon, 1 Sep 2014, Oliver Keeble wrote: > >> From my discussion with Romain, transmission of the DN is fine as long >> as it's encrypted. >> >> Oliver. >> >> On 01/09/14 15:20, Julia Andreeva wrote: >>> >>> We do need user DN for monitoring and popularity applications. >>> >>> Cheers >>> >>> Julia >>> >>> >>> On Mon, 1 Sep 2014, Lukasz Janyst wrote: >>> >>>> AFAIK, most of dCache sites use xrootd proxies, so they are likely >>>> affected, so is EOS, but fstreams have not been configured for Castor. >>>> >>>> Is it sufficient that we encrypt the fstreams or do you want us not >>>> to send the DNs at all? >>>> >>>> Cheers, >>>> Lukasz >>>> >>>> On 09/01/2014 03:04 PM, Oliver Keeble wrote: >>>>> >>>>> This is not a DPM issue - it's the xrootd fstream which sends out this >>>>> information so standard xrootd installations will also be affected. >>>>> dCache may be different, I don't know if they implemented this >>>>> themselves or not. >>>>> >>>>> On 01/09/14 13:48, Andrea Manzi wrote: >>>>>> Hi Romain, >>>>>> do you know if the problem affects only DPM-xrootd or all xrootd >>>>>> deployments are affected ? >>>>>> thanks >>>>>> Andrea >>>>>> >>>>>> On 01 Sep 2014, at 11:41, Romain Wartel <[log in to unmask] >>>>>> <mailto:[log in to unmask]>> wrote: >>>>>> >>>>>>> Domenico, Matevz, >>>>>>> >>>>>>> Just to close the loop; Please find the information below. The EGI >>>>>>> CSIRT, as well as WLCG operations coordination are coordinating this >>>>>>> issue. >>>>>>> I expect you will be contacted "officially" by the EGI security >>>>>>> vulnerability group (SVG) with an advisory before wednesday with all >>>>>>> the details. >>>>>>> >>>>>>> Then we would need you to look into this asap and report back on >>>>>>> what >>>>>>> corrective actions can be taken. >>>>>>> >>>>>>> Cheers, >>>>>>> Romain. >>>>>>> >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> *From: *Romain Wartel <[log in to unmask] >>>>>>>> <mailto:[log in to unmask]>> >>>>>>>> *Subject: **xrootd - user DN information* >>>>>>>> *Date: *1 Sep 2014 10:46:21 GMT+2 >>>>>>>> *To: *Maria Alandes Pradillo <[log in to unmask] >>>>>>>> <mailto:[log in to unmask]>>, Oliver Keeble >>>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>> >>>>>>>> Maria, Oliver, >>>>>>>> >>>>>>>> Here is the information I have regarding the user DN usage for >>>>>>>> monitoring in xrootd. >>>>>>>> >>>>>>>> I think the correct Indico link is >>>>>>>> https://indico.cern.ch/event/197803/session/0/contribution/10/material/slides/0.pdf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Our policy on this topic is at >>>>>>>> https://edms.cern.ch/file/855382/5/JobAccountingDataPolicy-v1.0.pdf >>>>>>>> >>>>>>>> "Each site is responsible for sending its accounting records on a >>>>>>>> regular basis, e.g. daily, with at >>>>>>>> least user DNs encrypted in transport, to a central data base >>>>>>>> defined >>>>>>>> by the Grid. This database is >>>>>>>> located at an Accounting Data Centre (ADC). The location of the ADC >>>>>>>> needs to be chosen >>>>>>>> carefully according to data privacy laws. " >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Romain. >>>>>>>> >>>>>>>> Begin forwarded message: >>>>>>>> >>>>>>>>> *From: *Sven Gabriel <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>>> *Subject: **[Irtf] more atlas fun* >>>>>>>>> *Date: *1 Sep 2014 08:14:12 GMT+2 >>>>>>>>> *To: *IRTF <[log in to unmask] <mailto:[log in to unmask]>>, >>>>>>>>> David >>>>>>>>> Groep <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>>>> *Reply-To: *Incident Response Task Force <[log in to unmask] >>>>>>>>> <mailto:[log in to unmask]>> >>>>>>>>> >>>>>>>>> This is easy, .. here we have an violation of a couple of our >>>>>>>>> policies on how >>>>>>>>> th handle user privacy data. >>>>>>>>> >>>>>>>>> "....The xrootd monitoring infrastructure sends user DN >>>>>>>>> information >>>>>>>>> and >>>>>>>>> all user actions in cleartext over UDP packets across to SLAC >>>>>>>>> in the >>>>>>>>> US for monitoring. They are even open about it: .." >>>>>>>>> >>>>>>>>> https://indico.cern.ch/event/197803/session/0/material/slides/0 >>>>>>>>> >>>>>>>>> ... Mitigation can be done by blocking OUTBOUND UDP apckets on >>>>>>>>> each >>>>>>>>> DPM xrootd host, in particular the headnode, but this is >>>>>>>>> obviously not >>>>>>>>> done by default. >>>>>>>>> >>>>>>>>> DROP udp -- anywhere anywhere udp spt:53193 >>>>>>>>> DROP udp -- anywhere anywhere udp spt:55721 >>>>>>>>> DROP udp -- anywhere atl-prod05.slac.stanford.edu >>>>>>>>> <http://atl-prod05.slac.stanford.edu/> >>>>>>>>> ...." >>>>>>>>> >>>>>>>>> Does IRTF wants to send out an advisory to all sites to apply the >>>>>>>>> same FW >>>>>>>>> rules? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Sven >>>>>>>>> -- >>>>>>>>> ======== >>>>>>>>> Sven Gabriel >>>>>>>>> >>>>>>>>> Nikhef, Dutch National Institute for Sub-atomic Physics >>>>>>>>> Group Computer Technology / Room: H1.59 >>>>>>>>> Phone: +31 20 5925103 >>>>>>>>> Science Park 105 / 1098 XG Amsterdam / The >>>>>>>>> Netherlands_______________________________________________ >>>>>>>>> Irtf mailing list >>>>>>>>> [log in to unmask] <mailto:[log in to unmask]> >>>>>>>>> https://mailman.egi.eu/mailman/listinfo/irtf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Romain Wartel >>>>>>> Security Officer >>>>>>> Worldwide LHC Computing Grid >>>>>>> CERN, IT Department >>>>>>> CH-1211 Geneva 23, Switzerland >>>>>>> >>>>>>> http://www.cern.ch/LCG >>>>>>> http://cern.ch/security >>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>> <[log in to unmask] <mailto:[log in to unmask]>> >>>>>>> >>>>>> >>>>> >>>> >>>> >> >> -- >> Oliver Keeble Information Technology Department >> [log in to unmask] CERN >> +41 76 487 5965 CH-1211 Geneva 23 >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >> -- Oliver Keeble Information Technology Department [log in to unmask] CERN +41 76 487 5965 CH-1211 Geneva 23 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1