Home   Info   DevZone   Wiki   UsersWeb  |  MainWeb  |  InfoWeb  |  DevZoneWeb  |  SupportWeb
[ KernelSecuritySupport ] [ not logged in ] [ Web: Imported ] goto:  options [ get info on or edit ] [ login or new user ] [ list of topics, hubs & nodes, or recent changes ]

I have an idea about a possible kernel-level (or JVM-level) support for security.

Main idea: Security manager may and can control any access to any and all methods and fields. It may use Java default access control, or change it to be more flexible and power.

Current Java usage of Security Manager: if( System.getSecurityManager() != null ) { // ask SecirityManager if this call is allowed }

Implementation: Security Mamager has some fixed methods - checkRead(), checkWrite(), checkCall() and some others. When bytecoder (interpreter or JIT or verifyer) see a opc_invoke... or opc_getstatic, opc_putstatic, opc_getfield, opc_putfield - they ask Securuty manager sending to it a java.lang.Class object of caller and java.lang.reflect.Fields or java.lang.reflect.Method of destination and reaquared access (read/write/execute). Manager answers: yes/no/use defaults. Defaults are: for application - check private/public/protected access, for applet additionaly - deny access to native methods. More than that - Security manager may override this defaults.

Advantages: - more security: even methods that do not ask Security Manager may be managed by it, and all native methods under control - more power: fields access is under scuryity too - more flexibility: Security Manager may extend security scheme by adding read-only access, ACL and so on. For example: public private int myReadOnlyField; or public immutable class String {...} - more freedom for programmers: there is no need to declare methods and fields to be private - we may use read-only access and ACL-controlled access. So, more classes and methods may be overriden, thus - more possibility for code reuse. - speed-up the Java: read-only access is much faster, so "A string".length() may be optimized into "A string".count without breaking security, and so on.

imho the "read-only" access you described, should be an optimization of the VM - if the VM could prove that only "Xload <local>;Xreturn;" (X="i" e.g.) is the code of a method, it could skip the call and put the value on the opstack.

-- TherP 19-MAR-1998

Content of these pages are owned and copyrighted by the poster.
Hosted by: