Practical Dynamic Modules (OSGi) Security Protecting More Than Just Data David Smith James Gould VeriSign 201
AGENDA > Background on OSGi > Security per OSGI spec > Security beyond OSGI spec
Background on OSGi > Why use OSGi? – Modularity – Service-oriented architecture – Hot-deployable updates – Multiple versions of code in residence – Hot-swappable versions > Ideal for highly available, highly adaptable applications > OSGi containers include: – Eclipse Equinox – Apache Felix – Knopflerfish
Bundle Lifecycle Starting , Installed, Started Resolved Stopping, Stopped
OSGi Layers Security Service Lifecycle Module
What Interactions Have To Be Secured? Application Management Bundle Bundle user admin System Bundles
Your Application Is A Castle
Keep Services Separated
Limiting Who Talks To Whom
What Security is Defined in the OSGi Spec? > Java 2 Security! – Use of Security Manager, Security Policies with Permissions > Permission Admin Service > Conditional Permission Admin Service > User Admin Service
What Security is Not Defined in the OSGi Spec? > Truly cross-cutting security apart from Java 2 Security > Java Authentication and Authorization Service (JAAS) integration > Securing the container from bad people > An easy way to apply user-based, declarative access protections – No @annotations – Only programmatic security – Not declarative
Java 2 Security > Let’s walk through memory lane? > Protect what bundles can do – Bundles granted permissions based on code base and jar signing – Programmatic checking permissions in bundles
Java 2 Security Steps > Enable Security Manager -Djava.security.manager > Define security policy in policy file -Djava.security.policy=<file> > Create custom permissions or use java.security.BasicPermission new BasicPermission(“displayReports”); > Check permissions in protected code segments SecurityManager sm = System.getSecurityManager(); if (sm != null) sm.checkPermission(new BasicPermission(“displayReports”));
Sample Policy File keystore “jazoon.jks”; grant codeBase "file:Untrusted*" { permission java.io.FilePermission "<<ALL FILES>>", "read"; }; grant signedBy ”jazoontest" { permission java.io.FilePermission "<<ALL FILES>>", "read, write, delete, execute"; }; grant { permission java.security.AllPermission; };
Keystore and jarsigner $ keytool -list -keystore jazoon.jks –storepass <pass> Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry jazoontest, May 25, 2010, keyEntry, Certificate fingerprint (MD5): 93:48:DC:4B:E5:E3:B2:05:F2:9B:A4:74:73:22:A1:C9 }; $ jarsigner –keystore jazoon.jks jazoontest.jar jazoontest Enter Passphrase for keystore: <pass>
Java 2 Security Protection Domains AccessControlContext If all Protection Domains don’t context = imply the permission, then a Class Loader A AccessController.getContext SecurityException occurs (); B.doAction() Class A Protection Domain A Class A, Class B, and File must imply FilePermission( file , “write”) ProtectionDomain .implies( pe Class Loader B rm ); File.createTempFile(“pre”, Class B Protection Domain B null); System Class Loader Security.checkPermission( new FilePermission( file , File System PD “write”));
Use of AccessController.doPrivileged() What if B.doAction() needs to AccessControlContext context = create a temp file independent of AccessController.getContext(); Class Loader A Class A’s permissions? context.checkPermission( perm ); B.doAction() Class A Protection Domain A ProtectionDomain.implies( perm ); Use AccessController.doPrivileged! Class Loader B AccessController.doPrivileged( Class B Protection Domain B new PrivilegedAction() { public Object run() { File.createTempFile( System Class Loader “pre”, null); return null; } File System PD });
Java 2 Security and JAAS > The Authorization of JAAS is handled by Java 2 Security > Policy grant supports Principals to define Permissions for users grant Principal com.acme.MyPrincipal “jim” { permission java.io.FilePermission “/home/jim/-”, “read, write, delete, execute”; } > To include user Principals with Protection Domain use Subject.doAs Subject.doAs(subject, new PrivilegedAction() { public Object run() { File newFile = new File(“/home/jim/test.txt”); newFile.createNewFile(); return null; }) ;
OSGi Permission Admin Service > What is missing from Java 2 Security for OSGi? – Define permissions based on bundles (location) – Allow management agent to lookup bundle permissions – Allow management agent to manage bundle permissions > Superseded by Conditional Permission Admin Service > Features – Permissions persisted – Support for default permissions – OSGi service management interface – Integration into Bundle Protection Domains
Setup Management Agent > Default permission of AllPermission > First bundle to assign permissions wins! – Management Agent must load first – Management Agent must give itself AllPermission > Example permAdmin.setPermissions( context.getBundle().getLocation(), new PermissionInfo[]{ new PermissionInfo( AllPermission.class.getName(),"”,"")});
OSGi Permission Admin Service Interface PermissionInfo[] getDefaultPermissions(); String[] getLocations(); PermissionInfo[] getPermissions(java.lang.String location); void setDefaultPermissions(PermissionInfo[] permissions); void setPermissions(String location, PermissionInfo[] permissions);
OSGi Permission Admin Service Flow Application Bundle Application Application PD doService Service Bundle hasPermission Service Service PD hasPermission execute Framework hasPermission Framework PD Framework Permission Permissions Service Admin Service Agent setPermissions
OSGi Conditional Permission Admin Service > What is missing from Permission Admin Service? – Permission Admin Service dependency on Bundle location as identifier – Not flexible for complex security models > Features – Introduction of ordered security conditions – Allow and deny policies – Support for local bundle permissions – Mutable and immutable conditions – Immediate and postponed conditions
Conditions > A Condition determines if a set of Permissions apply for a Bundle > A Condition is instantiated by the Bundle Protection Domain – Reference from Condition to Bundle > Features – Can be custom – Mutable – Postponed > Implying a Permission with Conditions – Is the Condition satisfied? – Are one of the permissions applied? – Policy access type (ALLOW or DENY) determines success or failure
Local Permissions > Allow Developer to specify what Permissions are needed by Bundle – Maximum Permissions for Bundle > Defined using Bundle Permission Resource in the Bundle – OSGI-INF/permissions.perm > Example # Require all FilePermissions (java.io.FilePermission "<<ALL FILES>>” "read, write, delete, execute”)
ConditionalPermissionAdmin Interface AccessControlContext getAccessControlContext( String[] signers); ConditionalPermissionUpdate newConditionalPermissionUpdate(); ConditionalPermissionInfo newConditionalPermissionInfo( String name, ConditionInfo conditions[], PermissionInfo permissions[], String access); ConditionalPermissionInfo newConditionalPermissionInfo( String encodedConditionalPermissionInfo);
OSGi Conditional Permission Admin Service Flow Application Bundle Application ApplicationPD doService Service Bundle hasPermission Service Service PD hasPermission hasPermission execute Framework Conditional Conditional Framework PD Framework Permission Permissions Service Admin Service hasPermission Security Manager commit Permission Agent Permissions Admin Service setPermissions
OSGi Effective Permissions > With Java 2 Security, Permission Admin Service, Conditional Permission Admin Server, and Local Permissions how is the effective permissions determined? – Java 2 Security always applies that can be extended with Implied Permissions – Local Permissions intersected with the Permission Services – Permission Admin Service takes precedence over Conditional Permission Admin Service
OSGi Effective Permissions Local Permissions Java 2 Permissions & Implied Permissions
Limiting What Outsiders (Users) Can Do
OSGi User Admin Service > What is missing from Permission Admin Services? – User level authentication and authorization! > Features – Contains Users, Roles, and Groups – Used to authenticate users – Used to create Authorization objects for authorizing user actions – Support for Basic (any) and Required (all) roles > Does not integrate with JAAS or Java 2 Security for user level security – Access to User Admin Service done via Java 2 Security
Role, User, Group, and Authorization roles Role Authorization 1..n user User roles Group
Recommend
More recommend
