MWSG7 Open Issues and resolutions

1. MWSG7Open Issues and resolutions Summary of the discussions in the 7th MWSG Amsterdam, 14 and 15th December, 2005 Issues: • Detecting ill-configured nodes • GUIDs • Delegation Interface • Glexec on worker nodes • CA namespace constraints implementations/SwissSign • Rare RDN components • 1SCP • Data management security model disc.

2. Detecting ill-configured nodes • Single script to detect security misconfiguration on a node • E.g. CRLs not updated, CA invalid, unmatched parts of a keypair … • useful for debug sessions. • Not be deployment specific (so not SFT style) • Depends on the RPM list • A script is available, can be used • Not much interest in it (yet)… • Linked off the agenda page

3. GUIDs • Deferred • Refers to ‘Grid User IDs’ • Work out common strategy for Grid username with SA1.

4. Delegation Interface • Akos or Joni to write a WDSL that is GT4 compatible but does not use WSRF • Basic elements are there and available to Akos • GT4 uses common key for all delegations (but this is an implementation issue, gLite uses currently a key per session) • Number of calls needed to to delegation in gLite and GT4 is the same (==2) • Timeline for implementation needed • Email summary of what to do: Akos, before Dec 21 • Implementation of this: • Java: Ricardo++, end of development by end of Jan • C: Andrew, end of development by end of Jan • Big Party: GGF16 (Olle to write the document)

5. GLexec on worker nodes • Reason for this topic: need of certain VOs to override priority within the VO for their members • The glide-in then runs with a generic user ID and then may change ID on the worker node and fetch a new job • This is a bot net • Issues: • Tracability: who submitted the job • glexec records changes in the JobRepository (a DB) • This must be documented for incident repsonse/handling • Is a scheduler/batch system still needed? • Needed for inter-VO scheduling • Only course-grained fair-share • From the other side: how can a site ensure that its local users get the best service, whilst acting within the VO, regardless of any VO priorities? • Is a good use case • Need a scoring system with both inputs • Condor could do that? • How is the original user’s cert preserved • Akos: pushed through the chain • A compromised bot submitted still kills the entire VO • Context: LHCb may likely be doing this already • Accountability problems • CPU acocunting will be accounted to the submitting bot user • Walltime will be always zero in the batch system accounting • Certified applictions • ‘servicizing’ the application could be the only true solution • TC or VMs: still a sufficiently constraint application needed • Solution: better scheduler, problem is with LSF that is constraint as far as policies in concerned. MAUI and Condor are OK • Need to define minimum requirements for batch schedulers • Only use this hack for LSFsites • The MWSG is UNHAPPY (LCG) with this model • UNICORE: does not support inter-job priority scheduling • This recommendtion (NOT to do it) misu be made known widely and in advance • Sites should be informed, DK to take up this issue

6. Namespace Constraints/SwissSign • Explained problem with the SwissSign Bronze example, but this holds for many others as well (CNRS, ESnet, …) • Relying party-defined Namespace Constraints are needed (so they cannot be embedded in the certs) • Signing_policy files are not recognised except in legacy GT C-based parts • Efforts in GGF have stranded in academic discussions • Urgent because of open vulnerability • Andrew: isn’t this authZ? Anyway, changing authZ software is far easier • Some java-based systems can install a non-selfsigned cert in the trusted store and get it to work (Unicore supports that mode) • Joni: this {may, does, *} hold for the TrustManager as well • We need to get a solution in a very short time • No resolution yet, needs to discuss over dinner

7. Namespace Constraints: currently supported things for signing policy files

8. Namespace Constraints • Singing_policy file IS needed. • Andrew: implement at AuthZ level • Implementation • Along lines of current GGF CAOPS WG draft • Use “/C=dfs/O=dsfsd/CN=dfsd” style naming • Wildcards: regex-style • AuthZ/AuthN? • For gridsite: in the AuthZ part of the code • For Java: in the TrustManager • File naming: ‘<hash>.namespaces’ • Timescale? • GridSite: mid-Feb. • Java TrustManager: mid-Feb. • Cog: ? • Unicore: (non critical? Jules will check) • Will appear in the Release 1.1 of the IGTF distribution (early Jan) • Later resynch with GT needed

9. Rare RDN components • Resolved over tea

10. DM security model • Presentation on the agenda page