Storage Element Security

1. Storage Element Security Jens G Jensen, j.jensen@rl.ac.uk WP5 Barcelona, 12-16 May 2003

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

3. 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 Current implementation

4. The Copy problem • (SRM)Copy copies a file from one SE to another: Copy('se.rl.ac.uk/moob/bazoink', 'se.cern.ch/fazop') • 3rd 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…

5. The Apache proxy problem Application (SE core) • 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… Apache mod_ssl OpenSSL

6. 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

7. 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)

8. 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

9. A word about VOMS TRUST • 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…? AUZ mgr (parse only) SE CORE GACL

10. 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

11. 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

12. 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]

13. 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.

14. 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’

15. 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.