Blackboard Building Blocks

Blackboard Building Blocks Framework and Security Tracy Engwirda, Senior Consultant – Asia Pacific Wednesday, April 2, 2014

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?

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

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

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

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.

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; }

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

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

Customizing Privileges

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

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

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

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

Basic Class Hierarchy

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

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

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

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

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

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

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

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; } }

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

Example Initiates Stack Walk Terminates Stack Walk

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

Example Policy File Entries Tomcat.policy // 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"; }

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

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

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

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

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

Blackboard Permissions <permission type=“persist” name=“Content” actions=“create,modify,delete”/> <permission type=“attribute” name=“user.authinfo” actions=“read,write”/>

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

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

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)

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…

Example Permissions <permissions> <permission type=“socket” name=“api.google.com” actions=“connect”/> <permission type=“runtime” name=“accessDeclaredMembers” actions=“”/> <permission type="java.util.PropertyPermission" name="java.protocol.handler.pkgs" actions="write"/> </permissions>

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

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?

Tips – Common Restrictions • System.getProperties() • returns a mutable copy of the system permission; thus you need <permission type=“java.util.PropertyPermission”name=“*” actions=“read,write”/> • Reflection requires runtime permission • Spawning a process requires a runtime permission

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

Thank You Demos to Follow >

Blackboard Building Blocks