1 Andrew Hanushevsky - CHEP, February 7-11, 2000 Practical Security In Large Scale Distributed Object Oriented Databases Andrew Hanushevsky Stanford Linear Accelerator Center Produced under contract DE-AC03-76SF00515 between Stanford University and the Department of Energy

2 Andrew Hanushevsky - CHEP, February 7-11, 2000 Our Motivation & Challenge n Motivation u Protect data from unauthorized access or modification n Challenge u Supply security to an existing DBMS, Objectivity/DB F Authentication ( who am I ), Authorization ( what can I do ), Enforcement F Handle very large database collections ( tera-databases and peta-bytes ) u Support any authentication or authorization model F At least private (e.g., Kerberos) and public key models F Authentication and authorization models are independent F Sufficiently extensible to handle future protocols and models u Easily implementable an deployable F Ability to use existing security infrastructure F Package system in installation replaceable units

3 Andrew Hanushevsky - CHEP, February 7-11, 2000 Critical Solution Areas n Packaging u Determines ease of deployment F Replaceable shared libraries n Architecture u Determines ease of implementation F Layered object-oriented components n Protocol u Determines extensibility F Tunneled, single-challenge, optionally arbitrated protocol

4 Andrew Hanushevsky - CHEP, February 7-11, 2000 AMS Generic Authentication Protocol Architecture Security & Database Protocol libooseccl.so protocol oofs ooss Objectivity Kernel application Authentication and Authorization  Replaceable

5 Andrew Hanushevsky - CHEP, February 7-11, 2000 Effects of Architecture & Packaging n Security protocol is tunneled via database protocol u Protocols are effectively independent F Changes in one do not affect the other n Objectivity kernel mediates client interactions u Same security used by every application and objectivity tool n Replaceable oofs mediates server interactions u Can implement any kind of enforcement policy n Security “linked” in via replaceable shared library u Can implement any kind of authentication or authorization model F Standard authentication model is Kerberos F Standard authorization model is capability-based

6 Andrew Hanushevsky - CHEP, February 7-11, 2000 Generic Authentication Protocol n Extensible u Can accommodate diverse authentication models u Example follows F Private vs public key authentication

7 Andrew Hanushevsky - CHEP, February 7-11, 2000 Private Key (symmetric) Authentication Protocol Get tgs ticket for client c Ktgs, Ks1>Kc Get ticket for service x Ktgs Ks1 Kx, Ks2>Ks1 Kx Ks2 Perform action y Kservice Ksession TicketAuthenticator E -1 k-private (E k-private (text)) = text

8 Andrew Hanushevsky - CHEP, February 7-11, 2000 AMS Generic Authentication Protocol (Private Key) Get security information Database request Kx Ks2 libooseccl.so

9 Andrew Hanushevsky - CHEP, February 7-11, 2000 Public Key (asymmetric) Authentication Protocol Authenticate challenge Kx-prv Get public key x c Kc-prv Perform action y Kx-pub Get public key c Kc-pub E -1 k-public (E k-private (text)) = text = E -1 k-private (E k-public (text))

10 Andrew Hanushevsky - CHEP, February 7-11, 2000 AMS Generic Authentication Protocol (Public Key) Get security information Database request c Kc-prv &P-dass,challenge Kx-prv libooseccl.so Get public key x Kx-pub Get public key c Kc-pub

11 Andrew Hanushevsky - CHEP, February 7-11, 2000 Why is Generic Authentication Protocol Extensible? n Tunneling u GAP is simply a wrapper for an arbitrary authentication protocol u Database protocol forwards wrapped data without inspection F Wrapper added and removed by shared library code n GAP can support virtually any protocol u Allows out-of-band arbitration n CAP can support multiple protocols u Server determines which protocols are available

12 Andrew Hanushevsky - CHEP, February 7-11, 2000 AMS Generic Authentication Protocol (Arbitrary) Get security information Database request Authentication protocol specific information &P-krb5,  &P=dass,  &P=pgp2,  libooseccl.so Out of band communications Can be heterogenous

13 Andrew Hanushevsky - CHEP, February 7-11, 2000 Distributed Heterogeneous Environments Each object independent Object created based on “info” One per physical ams connection Handles credential generation Always ams-specific Interface Handles It

14 Andrew Hanushevsky - CHEP, February 7-11, 2000 Client Security Interface oofsAMSClientSecurity *oofs_createSecurityContext( const struct sock_addr_in &netaddr_of_ams, const oofsAMSSecurityIdentifiers &ams_security_info); createSecurityContext() creates an ams-specific security object: class oofsAMSClientSecurity { public: int getCredentials(ooUInt32 operation. const char *pathname, oofsAMSSecurityCredentials &cred); oofsAMSClientSecurity.getCredentials() called by the ams client-side kernel prior to each ams interaction based on indicated operation & path: void oofs_deleteSecurityContext(oofsAMSClientSecurity *security_object); deleteSecurityContext() delete the security object when connection closed:

15 Andrew Hanushevsky - CHEP, February 7-11, 2000 Server Authentication Interface getSecurityToken() provides ams-specific security information sent to client: class oofsAMSAuthentication { public: oofsClientInfo *getClientInfo(oofsCredentials *credentials, oofsErro &error_object); int Authenticate(oofsCredentials *credentials, oofsClientInfo *information); oofsAMSAuthentication.getClientInfo() called by the oofs at open time and cretain file meta-data operations (e.g., deletion) while Authenticate() is called on subsequent operations: class oofsFileSystemDesc { public: int getSecurityToken(oofsSecurityToken &buffer. struct sock_addr_in &netaddr_of_client, oofsError &error_object);

16 Andrew Hanushevsky - CHEP, February 7-11, 2000 Authorization Challenge n Unencumbered AMS u Can only protect what AMS understands F Database files n Size of all federations u Billions and billions of databases F Amount of data is a moot point n Access control list model unmanageable u Too many databases to protect F Don’t want to record usernames in many places n Capability model is manageable u Few users relative to number of databases F Usernames recorded only once F Each user given access to arbitrary regions of any federation

17 Andrew Hanushevsky - CHEP, February 7-11, 2000 Standard Capability Model libooseccl.so u abh rw /objy/databases/usr/abh r /objy/databases access()yes or no client database request

18 Andrew Hanushevsky - CHEP, February 7-11, 2000 Server Authorization Interface oofsClientInfo class provides username, instance, and security realm: class oofsAMSAuthorization { public: int Access(oofsClientInfo *information, char *path, int operation); oofsAMSAuthorization.Access() called by the oofs at open time and certain file meta-data operations (e.g. deleteion): class oofsClientInfo { public: char *Id(); char *Instance(); char *Realm(); char *User();

19 Andrew Hanushevsky - CHEP, February 7-11, 2000 Summary n Scalable u Standard is Kerberos & capabilities n Extensible u Can support virtually any authentication & authorization model n Replaceable u Packaging allows installation to easily use existing infrastructure n Automatic u Applications and Objectivity tools automatically use supplied security u Circumvention detected and rejected