Security

1
Blackboard Building Blocks
Framework and Security
Tracy Engwirda, Senior Consultant Asia Pacific
Wednesday, November 11, 2009
2
Security High Level View

• Authentication
• Who is using the system?
• Authorization
• Can that user do what theyre 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() BbSe
ssion bbSession sessionService.getSession(
request ) AccessManagerService accessManager
(AccessManagerService)BbServiceManager.lookupServ
ice( 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 couldnt 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(Priv
ilegedActionException 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.policy
// Tomcat gets all permissions grant codeBase
"filetomcat.home/lib/-"
permission java.security.AllPermission grant
permission java.util.PropertyPermission
"java.version", "read" permission
java.util.PropertyPermission "java.vendor",
"read"
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-controltrue
• 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 cant 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 cant
  get the (hashed) password

33
Blackboard Permissions

• ltpermission typepersist nameContent
  actionscreate,modify,delete/gt
• ltpermission typeattribute nameuser.authinfo
  actionsread,write/gt

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 extensions 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

• ltpermissionsgt
• ltpermission typesocket nameapi.google.com
  actionsconnect/gt
• ltpermission typeruntime nameaccessDeclaredMe
  mbers actions/gt
• ltpermission type"java.util.PropertyPermission"
  name"java.protocol.handler.pkgs"
  actions"write"/gt
• lt/permissionsgt

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 dont test their code with a
  security manager, so they dont know what theyre
  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 ltpermission typejava.util.Propert
  yPermissionname actionsread,write/gt
• 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 gt