Transcript Security

Blackboard Building Blocks
Framework and
Security
Tracy Engwirda, Senior Consultant
– Asia Pacific
Wednesday, April 6, 2016
Security – High Level View
Authentication
– Who is using the system?
Authorization
Can the code what it is trying to do?
– Can that user do what they’re trying to do?
Privacy
– Is the users’ data kept private?
Integrity
– Has the data been tampered with?
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
User
SystemRole
* 1
1
*
*
Entitlement
**
*
Membership
CourseRole
* 1
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
Principal
+getName()
0..* Has
1
Has
Class
+getProtectionDomain()
1
1
+getCodeSource()
+getPermissions()
1
PermissionCollection
Has
ProtectionDomain
1
1
Permissions
+add()
+implies()
+elements()
Has
Contains
*
0..*
1
CodeSource
Permission
+getCertificates()
+getPermissions()
+implies(in codeSource : CodeSource)
+implies()
+getName()
+getActions()
AllPermission
checks
SecurityManager
+checkPermission()
BasicPermission
PersistPermission
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
SecurityManager.checkPermission()
Query.executeQuery()
DbConnectivityPrivilege.run()
NewBaseDbLoader.loadObject()
AnnouncementDbLoaderImpl.loadById()
ExtensionClass.foo()
ExtensionServlet.service()
Terminates Stack Walk
Stack Walk
Call Sequence
ConnectionManager.getConnection()
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 >