Introduction

This is a list of class 2 and class 3 services, run on behalf of wLCG VOs at sites. A reminder of the terminology:

  • A class 1 service does not require any privileged access to site services. For example, suppose the site is located in university A, the VO box could be run in university B, as long as the network bandwidth and latency between A and B meets the service requirements.
  • A "class 2 service" is one that, by design, must be run inside the trusted subnetworks of a grid site. For example, some VOs used to use the VO box as a software distribution mechanism; this meant the VO box had to be inside the same trusted subnet, as the same NFS share had to be mounted between the VO box and the WNs.
  • A class 3 service we define as one in which a VO-constructed modification is made to trusted software services running at the site.

Any software at the site can potentially contain exploitable vulnerabilities. One might imagine that VO-constructed software is more concerned with functionality and less with security (examples have been seen). For an exploited class 2 service, an attacker could quickly become root on the VO box, which puts all other machines in the same trusted segment at risk. For an exploited class 3 service, an attacker has direct access to both a trusted service and a trusted machine.

For more information, see e.g. the presentation at the January 2015 GDB. Class 3 services had not yet been foreseen at that point.

List of services

  • ATLAS N2N Service: this needs to have access to the SRM namespace, and is run as a plugin to the site's xrootd server. Class 3.
  • PerfSONAR Service: the purpose of this is network monitoring. Take the example of disk servers which are connected via the LHC OPN; sometimes such servers are allowed to participate in the OPN only by virtue of residing in a special subnet. If the PerfSONAR box does not reside in this same (trusted) subnet, the monitoring results may have little to do with the actual OPN network performance and reliability. Class 2

Most VO boxes used to be Class 2 by definition. For ALICE, ATLAS, and LHCb at least, this is no longer the case.

LHCb services

All LHCb Tier-1 VO-boxes are "Class 1" as defined in the introduction above. They do not need any previleged relation to the site and run on boxes with generic internet visibility and 3 specifically opened ports. They are there for the reasons below

  • Primarily to provide a distributed fail-safe destination for operational (DIRAC) requests for LHCb jobs on the grid. This is a temporary store of requests (not Data) in case of a temporary problem in contacting the services at CERN.
  • Secondarily to provide load-balancing instances of the DIRAC configuration which is the most queried service in DIRAC.

-- JeffTemplon - 2015-06-25

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r6 - 2015-07-28 - RajaNandakumar
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback