1. Blackboard Building Blocks Framework and Security Monday, September 14, 2015 Tracy Engwirda, Senior Consultant – Asia Pacific

2. Security – High Level View Authentication –Who is using the system? Authorization –Can that user do what they’re trying to do? Privacy –Is the users’ data kept private? Integrity –Has the data been tampered with? Can the code what it is trying to do?

3. Topics for Extension Developers Common Security Tasks –Authentication, Authorization Declaring Permissions –Often trial and error iteration… add a permission, get stopped by another one

4. Overview – Java Security JSSE – Java Secure Sockets Extension –SSL support, etc. –TLS, RFC-2246 JCE – Java Cryptography Extensions –Pluggable crypto provider framework Java GSS-API –Java bindings for Generic Security Services API (RFC-2853) CertPath API –API for examining certificate chains

5. Overview – Java Security JAAS – Java Authentication and Authorization Service –Pluggable Authentication –Authorization for code and principals Code Security Model –Who can do what –What code can do what

6. Language Features Type safety –Compile-time –Run-time Byte code verification –Well formed class files –No illegal sequences – e.g., check for stack underflow, etc.

7. Authentication for Extensions Simple, let the platform worry about it… BbSessionManagerService sessionService = BbServiceManager.getSessionManagerService(); BbSession bbSession = sessionService.getSession( request ); AccessManagerService accessManager = (AccessManagerService)BbServiceManager.lookupService( AccessManagerService.class ); if (! bbSession.isAuthenticated() ) { accessManager.sendLoginRedirect(request,response); return; }

8. Authentication for Extensions Access Manager coordinates with authentication providers to do the right thing Default providers –RDBMS –LDAP –Web Server Custom providers

9. Authorization in Blackboard Role-based assignment –System role attached to user object –Course role attached to enrollment record Privileges attached to Roles –Editable –Check relies on the union of all relevant entitlements

10. Customizing Privileges

11. It All Comes Back To… Context! –You have the user, and thus the system role… –You have the course, and thus the course role... –Access control works against the full entitlements mask

12. Authorization for Extensions Authorization –Role-based checks – Deprecated... –Entitlement-based checks – Not finalized… PlugInUtil.authorizeForXXX() –authorizeForCourseControlPanel() –authorizeForSystemAdminPanel() –authorizeForCourse() –authorizeForContent()

13. Code Security Framework Leverage security inherent in the Java 2 Standard Edition framework Enforce certain API restrictions Enforce API usage disclosure –Manifest must declare required permissions

14. Code Security – Historical “Sandbox” model – JDK 1.0 –Applets just couldn’t do certain things –Hard to manage/understand “Trusted” model – JDK 1.1 –Permissions assignable to trusted code –Code (applets) could be signed “Domain” model – JDK 1.2 –Policy –Domains

15. Basic Class Hierarchy

16. Permission Class Permission –Abstract base class for all permissions –All Permission objects define a name and actions –Relationships can be created via implies( Permission ) BasicPermission –Concrete base class for most permissions

17. Classes Security information available through Class object –Object.getClass() ProtectionDomain –Encapsulates information about the classes physical source and associated permissions –Class.getProtectionDomain()

18. Classes PermissionCollection –ProtectionDomain.getPermissions() –List of permissions PermissionCollection.implies( Permission ) CodeSource –ProtectionDomain.getCodeSource() –Physical location of class (URL) Hierarchical: CodeSource.implies( CodeSource ) –Certificates

19. Security Checks SecurityManager.checkPermission( Permission ) –Other checkXXX() methods ultimately delegate to this method –This method, in fact, delegates to AccessControlManager For each frame in call stack –Get code source –Get permissions for code source –Requested permission implied by permissions collection? SecurityException thrown if check fails

20. Checking Permissions if( _modifyPermission != null ) { System.getSecurityManager().checkPermission( _modifyPermission ); }

21. Privileged Blocks Short-circuit stack walk If the current frame has permission, allow access Allows trusted code to perform actions that may not be granted to the caller –E.g., un-trusted code may not have network permission, but the database driver does

22. Examples We do not allow System Extensions to get raw database connections Our own code, which may be called by a System Extension, needs to get a database connection Solution: Privileged block –Code executing with more privileges can accomplish what it needs to

23. Example private class DbConnectivityPrivilege implements PrivilegedExceptionAction { private Query _query; private Connection _con; private DbConnectivityPrivilege(Query query, Connection con) { _query = query; _con = con; } public Object run() throws Exception { _query.executeQuery( _con ); return null; }

24. Example try { AccessController.doPrivileged( new DbConnectivityPrivilege(query, con)); } catch(PrivilegedActionException pae) { castException( pae ); }

25. Example Initiates Stack Walk Terminates Stack Walk

26. Policies Policies define the Permissions associated with code bases Default implementation uses a policy file Grant/deny permissions to code bases Grant/deny permissions to Subjects –New in JDK 1.4 with addition of JAAS

27. Example Policy File Entries // Tomcat gets all permissions grant codeBase "file:${tomcat.home}${/}lib${/}-" { permission java.security.AllPermission; }; grant { permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; } Tomcat.policy

28. Activating Security Run-time properties on the command line –-Djava.security.manager –-Djava.security.policy java.security – Configuration file for setting security providers –policy.provider – Class that is responsible for implementing the policy Default is sun.security.provider.PolicyFile

29. Blackboard Implementation wrapper.properties/tomcat.sh –Points to tomcat.policy service-config.properties –code-level-access-control=true –Can disable SecurityManager regardless of command line options Custom Policy implementation

30. Blackboard Implementation SecurityUtil.checkPermission() –Hides check for SecurityManager –Propagates Security Exceptions BbPolicy –Wraps code sources for System Extensions –Attempts to prevent “over-riding” You can’t just put permissions in the policy file

31. Blackboard Permissions blackboard.persist.PersistPermission –Name is the data object, actions are “read,create,modify,delete” –Base persister and loader classes check for permission

32. Blackboard Permissions blackboard.data.AttributePermission –Controls access to attributes on a data object –Naming convention allows single attributes or groups to be protected –E.g., untrusted code can load a user, but can’t get the (hashed) password

33. Blackboard Permissions

34. System Extensions Deployed as a web application with a unique code source –Code source is attached to /plugin directory, so it encompasses the /webapp and /config directories Manifest includes a permissions block –Some filtering to restrict certain permissions –Manifest is equivalent of policy file

35. System Extensions Enabling an extension at startup –Read permissions from database –Associate with web app code source –Register servlet context with Tomcat Registration of servlet context only occurs if extension is “Available” or “Unavailable”. Otherwise, no code may be executed

36. System Extensions Permissions block contains 0 or more permission elements Same semantics as “grant” entries in the standard Java policy file –No explicit deny Simple mnemonics for common types –Runtime, Socket, Persist, Attribute Type attribute can be any fully qualified Java classname –Must be a Permission sub-class, with two argument constructor (String, String)

37. Default Permissions Read/write access to extension’s home directory Read access to Blackboard root Read access to data (via APIs) Read access to system properties Everything else must be explicitly declared…

38. Example Permissions

39. Manifest Limitations No escape syntax –Properties that require user input, or information from local system, cannot be encoded in permission block

40. Tips Read the Javadoc for any third party libraries you are using –Many developers don’t test their code with a security manager, so they don’t know what they’re touching E.g., Axis configuration routines will throw SecurityException if run with a SecurityManager Think security… –What would you as an administrator want to see disclosed?

41. Tips – Common Restrictions System.getProperties() –returns a mutable copy of the system permission; thus you need Reflection requires runtime permission Spawning a process requires a runtime permission

42. Conclusion System Extensions have access to verify both authentication and authorization Administrators have an additional level of disclosure about what extensions will access

43. Thank You Demos to Follow >