Storage Element Security Jens G Jensen, WP5 Barcelona, May 2003

Contents Current Implementation File level access control User id in Mass Storage

Current implementation Apache path Uses standard Apache with mod_ssl …except for a GSI patch… …which doesn’t work with all proxies Web service path Uses Tomcat/Axis with Trustmanager plugin

The Copy problem (SRM)Copy copies a file from one SE to another: Copy('se.rl.ac.uk/moob/bazoink', 'se.cern.ch/fazop') –3 rd party copying –Creates the file in the target SE –Copies ACLs and other relevant metadata This does not (yet) exist! Requires delegation Of course we can steal the user’s proxy. But…

The Apache proxy problem If the root CA certificate is version 3 and has all the “right” extensions, then mod_ssl never sees the proxy-user-root certificate chain This is a problem with OpenSSL rather than something that can be fixed in mod_ssl Solutions… Application (SE core) Apache mod_ssl OpenSSL

Proxy problem, solutions… Use Globus GSI libraries? –Tricky, must be done in Apache where the socket is handled…? Rewrite the SSL verify callback? An “SSL-agent” which, similar to ssh-agent, stores the SSL context in a daemon that runs as the user + Can be used with any normal SSL server Secure, but need to modify clients (obviously) +/- Cannot be forwarded -Cannot be used from scripts

File level access control Need to authorise based on individual files: –permission(USER, SFN, operation)  {yes,no} Currently we use GACL –Permissions are {list, read, write, admin} We have an implementation but it is not yet integrated into the TB2.0 SE (it was written some time ago)

Multiple VOs Each VO has a separate namespace Everybody talks to the same port/endpoint Each user belongs to exactly one VO (pre- VOMS) The VO membership information is stored in a user profile (not a scalable solution) This information is usually generated from the gridmap file

A word about VOMS Bad news: VOMS may take some effort to support Good news: we expect others to do (most of) this work for us! If Trustmanager validates the VOMS proxy, the AUZ mgr must parse it and make the information avaliable to the core so the core can perform the authorisation If GACL handles the remaining tasks then it should be easy…? TRUST AUZ mgr (parse only) SE CORE GACL

Access and replication “Proper” model: –RM “owns” replicas, delegates permission to users Current model: –RM runs using the user’s credentails, so replicas are owned by that user… –What are ACLs on replicas? Presumably, Either RM must replicate ACLs along with the data (OK because users have admin permissions on the files they create) Or must use Copy() which automatically copies ACL However, Copy() doesn’t yet exist – needs delegation

User id in mass storage “Unfortunately”, users must be able to access files in MSS via non-SE (and non-Grid) paths This means: –MSS specific solutions (StFN, anyone?) –SE must run individual handlers as different local user ids (so need setuid root) –Local user id is picked from the gridmap pool –Group id is default group for the user

setuid root? A specific setuid wrapper wraps the handler that needs to run as a non-SE local user/group Wrapper is very small and does not depend on external libs (uses McNab’s gridmap code) DN is picked from environment! But… The wrapper refuses to run unless: –It is installed in the SE handler directory –It is installed using specific names (SE handler naming scheme) –It is run by the SE user only –SE user has no login shell [can be swicthed off at compile time] –It is run by a daemon [also compile time switch]

setuid root? When user uploads file to SE’s disk cache they typically write the file as a mapped local user (because the GridFTP server is not integrated into the SE, i.e. it runs as a separate application on the SE host) So we may need a setuid handler to chown to “se” How do we protect the SE’s disk cache? Non- integrated tools can write into cache, or modify files in cache Filenames in the cache are generally not human readable (guessable); files are generally world readable.

setuid root? Example from integration with WP2 software: Web service runs as user ‘tomcat4’ SE runs as user ‘se’ This is an integration problem – ideally everything should run as the same user Quick and dirty fix: Set permissions on edg_se_rmanman (common entry point into the core) to 4755: if run with effective uid root it immediately drops root privs by switching all user ids to ‘se’

VO production (subgroup) problem Some people in a VO must have write access to a directory, everybody else in the VO has read-only access. Gridmap file /PROD1/cmsprod1 /PROD2/cmsprod2 /USER1/cms001 /USER2/cms002 /USER3/cms003 /etc/passwd cmsprod1  w cmsprod2  w cms001  r cms002  r cms003  r Users with a “production DN” get mapped to a “VO” which in turn maps to a local user who has write permission in the MSS. The “normal” VO members get mapped to local read-only users.