river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Moving River into the Semantic Web with Codebase Services & Bytecode Analysis services.
Date Sat, 19 Sep 2009 06:51:41 GMT
The comments on security below are based on this research paper:


I can see how I could restrict access by making certain classes 
invisible to untrusted code using a class loader framework, however 
finer grained access control applied to methods looks rather difficult 
to implement. N.B. I tried contacting the paper's author, without luck.

I'm trying to figure out what the alternative, restricted view of the 
entity could be? It can't be a reflective proxy, that requires 
interfaces. Could it be an overridden copy of the class, created using 
reflection, where the restricted methods are overridden to hide the 
original method? Using polymorphism these would work in place of the 
original class, it wouldn't work for final classes or public fields, not 
ideal? Google-guice does something similar to this, however the paper 
above criticizes this approach as adding runtime overheads.

Anyone have any ideas?

N.B. I'm not getting much time near my dev workstation (Ultra80 Solaris 
10) right now, so haven't done anything about the River AR2 release, but 
will get there. Most of the information and my thoughts here have been 
collected while on the road. Note for anyone wondering about my health, 
I'm receiving treatment for a non-malignant brain tumor, it has shrunk 
by 2mm. Don't let that worry you about offending me with comments or 
questions however, I could use some assistance ;)



The guts of the paper on page 5 reads:

In a dynamically extensible software system, the trusted application 
core is defined in a parent
namespace, while child namespaces are created for defining untrusted 
software extensions (Figure
1). Core application services are exposed to the extension code by 
implicitly importing names
from the core application namespace to the extension namespace. ISOMOD 
is a run-time module
system designed for isolating untrusted software extensions. It does so 
by controlling the visibility
of names in the namespaces in which untrusted software extensions 
reside. Specifically, an
ISOMOD namespace enforces two kinds of control: (1) restricting the 
visibility of names that are
imported from the parent namespace, and (2) restricting the visibility 
of locally defined names.
When a name is placed under visibility control, an ISOMOD namespace may 
(a) control which
locally defined class can “see” the name, and (b) present an 
alternative, restricted view of the entity
to which the name is bound. Every ISOMOD name space is endowed with a 
custom name
visibility policy, which specifies visibility restrictions to be imposed 
on the names visible in the
namespace. When appropriately constructed, an ISOMOD policy may be used 
to selectively hide
core application services from untrusted extensions (Section 4.1 and 
4.2), or impose collaboration
protocols among classes defined in the extension namespace (Section 
4.3). A major contribution of
this work is the design of a policy language that can express a rich 
family of access control policies
as fine-grained visibility constraints.
An ISOMOD namespace is an instance of a user-defined class loader class. 
An ISOMOD class
loader performs extra checks on a classfile before converting it into a 
Class object. Specifically,
class definition is only authorized when no external accesses in the 
classfile are denied by the
policy. This late enforcement (i.e., load time) of visibility control 
distinguishes ISOMOD from
traditional module systems, in which visibility control is enforced only 
at compile time. It is this
feature that makes the ISOMOD module system into a viable protection 
An ISOMOD namespace may be constructed at run-time by an application 
core from an ISOMOD
policy. This late binding of access control policy to code not only 
supports the separate
maintenance of code and policy, but also supports the presentation of 
different views of the same
application core to different extensions.

Peter Firmstone wrote:
> Some Implementation design thoughts on Security:
> Security by Name space visibility and Trust within Package Class 
> loader's?
> If each package is segregated into its own class loader and all 
> dependencies required by that package have been determined by Code 
> base analysis, then visibility should be limited to the classes and 
> methods discovered by the codebase server analysis and enforced at 
> class loading time .
> A local namespace visibility policy (more fine grained than java 
> security policies) , might contain a list of allowable system methods 
> for code originating from untrusted entitites (even though the code 
> base is trusted and the code has been analysed). Any method signatures 
> in the downloaded code that didn't appear in the list as allowable, 
> would not be granted visibility, a default working set could be 
> created for distribution with River, all disallowed methods are 
> commented out.
> Then in the worst cast of trust, where neither the code base or the 
> origin of the code is trusted, the list of required dependencies and 
> methods declared by the code base analysis are only allowed if they 
> are allowed locally. So if a code base were to submit code with non 
> disclosed methods, those methods would not be accessible to the 
> untrusted code. The dependency analysis information provided by the 
> code base forms a contract between untrusted parties.
> Consider the following:
> 1. Code base A is trusted and has obtained it's code from another
> trusted entity (who ever uploaded the code to the code base server
> in the first place).
> 2. Code base B is untrusted.
> 3. Code base A is trusted and has obtained some code from Code base B
> which is untrusted.
> 4. Trusted and Untrusted code will be loaded into separate class
> loaders by a client JVM.
> Note: my reference to methods, include protected or public visibility, 
> the terminology may be freely interchanged with fields that are public 
> or protected also.
> Code base A could bundle and sign the trusted code, and bundle without 
> signing the untrusted code after analysis. (where bundle means 
> splitting an existing jar into multiple jar's after analysis, one for 
> each package).
> The client would receive a dependency analysis report from Code base 
> A, the client would restrict the visibility of the untrusted code to a 
> subset of declared methods that are allowed.
> Code base A, might later receive trusted code that is API compatible 
> with that of the untrusted code, this would be discovered by analysis. 
> From then on, Code base A would be able to provide trusted code, to 
> it's trusting clients when required.
> This could lead to the desirable situation where a Client is receiving 
> a marshalled object stream from an untrusted service or vice versa, 
> both entities could obtain trusted byte code for unmarshalling from 
> their own preferred trusted code bases, regardless of the source of 
> the marshalled object stream.
> In the worst case, code could be obtained from an untrusted code base, 
> however that byte code would not be able to access any methods that 
> had not been declared as required dependencies by the code base, the 
> declared methods would also be vetted against the local security 
> policy. In the worst case the code would be available with degraded 
> functionality, but will not violate the local security and namespace 
> visibility policy, unpermitted methods would not be visible in the 
> untrusted package's class loader.
> However I've deliberately left out a scenario:
> Interoperability between trusted and untrusted code?
> What about untrusted application code interacting with trusted 
> application code? How does one restrict access for untrusted code? Who 
> is responsible for determining what methods should be accessible by 
> default, for application packages? The package might not exist in the 
> local JVM at load time, it may be downloaded later.
> The onus in this case would have to be placed upon the trusted 
> application package distributor (as trusted by the code base) who may 
> at their discretion, change what methods untrusted code can safely 
> have access to. Hence there will need to be a means for the code base 
> to allow and provide name space visibility policies for application 
> code also. Determining trust is left to the client. An unknown third 
> party may become trusted by a client, if that party is trusted by a 
> trusted code base. A friend of a friend so to speak.
> Perhaps trusted code should be limited to the codebase's declared 
> visibility requirements as an additional precaution, assisting with 
> analysis bug identification too. Perhaps different namespace 
> visibility policies could be developed for different trusted codebase 
> entities/identities, I'm not sure if this is an essential requirement, 
> however the implementation could be made extensible so as not to 
> exclude the possibility.
> One other point:
> Class load time delays caused by bytecode verification; perhaps 
> bytecode verification could be performed by the trusted code base, 
> eliminating the need to verify remote code, improving load time 
> response. Local code is not verified at load time by default. In this 
> case an administrator would trust their code bases and would not under 
> any circumstance allow bytecode to be utilised from untrusted sources. 
> But then with the New Verifier in Java SE 6 as a result of JSR202... 
> perhaps verification time has been mitigated somewhat?
> Anyone have any input or implementation suggestions?
> Regards,
> Peter.
> Peter Firmstone wrote:
>> Look forward to it mate,
>> N.B. this line should read:
>> * Codebase surrogates, for objects originating from periodically
>> disconnected services for clients to obtain their bytecode (they also 
>> require Refreshable References and
>> Xuid's)
>> Cheers,
>> Peter.
>> Gregg Wonderly wrote:
>>> Peter, I want to write up some questions and thoughts about this 
>>> post, but can't do that right now, hopefully I can in a day or so.
>>> Gregg Wonderly
>>> Peter Firmstone wrote:
>>>> I've had some more thoughts on Codebase services after spending 
>>>> time researching & reflecting.
>>>> Issues I'd like to see addressed or simplified using Codebase 
>>>> services:
>>>> * Codebase loss
>>>> * Codebase replication
>>>> * Codebase upgrades
>>>> * Codebase configuration
>>>> * Codebase surrogates, for objects originating from periodically
>>>> disconnected clients (they also require Refreshable References and
>>>> Xuid's)
>>>> * Bytecode Dependency Analysis & API signature identification, for
>>>> Package & Class Binary Compatiblity & ClassLoader Isolation
>>>> * Bytecode Static Security Analysis, repackaging & code signing.
>>>> On the last issue I've had some thoughts about Code bases being 
>>>> able to act as a trust mediator to receive, analyse, repackage, 
>>>> sign and forward bytecode on behalf of clients. The last two items 
>>>> above fit into the category of Bytecode Analysis service 
>>>> responsibilities for codebases. Prior to loading class files, a 
>>>> client can have a trust relationship with one or more preferred 
>>>> codebase providers. A code base provider also provides bytecode 
>>>> static analysis services for security and binary compatibility 
>>>> purposes.
>>>> I got thinking about this solution after reading about service 
>>>> proxy circular code verification issues for disconnected clients 
>>>> that project neuromancer exposed. A surrogate security verifier as 
>>>> well as a codebase surrogate.
>>>> All this would be implemented with minimal changes to services and 
>>>> clients configurations and no change to third party library code, 
>>>> unlike my evolving objects framework proposals.
>>>> After receiving a tip off from Michael Warres, Tim Blackman was 
>>>> gracious enough to share learnings from his research on class 
>>>> loader tree's. Tim built a prototype system using message digests 
>>>> and was considering implementing textual Class API signatures for 
>>>> identifying compatibility between different class bytecode's. Tim 
>>>> considered the textual API signatures when he found independent 
>>>> vendor compiler optimisations produced different bytecode, hence 
>>>> different SHA-1 signatures, although they have identical and 
>>>> compatible class API. I thought about this further and realised 
>>>> that Binary Compatiblity for class files and package change is far 
>>>> more flexible than source code compatibility. While Tim 
>>>> concentrated on API compatibility for ensuring objects that should 
>>>> be shared, could be, he found that groups of class files, based on 
>>>> dependency analysis (this is where the replacement ClassDep code 
>>>> came from), required their own ClassLoader's, hence there are a 
>>>> significant number of class loader instances required for maximum 
>>>> compatibility (without going into more detail).
>>>> In essence, the solution I'm striving for, is to solve the problem 
>>>> in a distributed world that OSGi solves in the JVM; segregation and 
>>>> isolation of incompatibility while allowing compatible 
>>>> implementations to cooperate. However I want an implementation 
>>>> without commitment to any particular container or module 
>>>> technology, so as not to force container implementation choices on 
>>>> projects that already have their specific container implementations.
>>>> Rather than reinventing another container technology, all jar files 
>>>> a service's client requires, could be uploaded to codebase 
>>>> services, just prior to service registration. The codebase service 
>>>> could analyse, repackage and sign the jar files into compatible 
>>>> bundles, dynamic containers if you wish, one for each ClassLoader, 
>>>> where each class loader represents a Package API group signature.
>>>> Using the uploaded jar files, the codebase services could generate 
>>>> and propagate analysis reports amongst themselves in a p2p fashion, 
>>>> such that between them, they could determine the latest binary 
>>>> compatible version of a package, such that the latest compatible 
>>>> version would always be preferred. Once the latest version is 
>>>> identified, a codebase service can verify, with it's own analysis, 
>>>> in order to confirm and report malicious or malfunctioning codebase 
>>>> servers. Newer versions of a Package, found to have broken Binary 
>>>> Backward compatibility, would be kept in a separate ClassLoader as 
>>>> determined by their API signature, thus incompatibility is 
>>>> isolated. There may be subgroups within a package, that could also 
>>>> be shared between incompatible package versions to provide improved 
>>>> class file and object sharing.
>>>> Hence a client receiving bytecode, could choose to channel it 
>>>> through one or more codebase servers that it has trust 
>>>> relationships with. A bytecode trust surrogate, the preferred 
>>>> codebase server could retrieve required bytecode that it doesn't 
>>>> already posses via lookup services of other codebase service 
>>>> locations. The bytecode recipient would retrieve analysis 
>>>> information detailing bytecode implementation security concerns 
>>>> prior to loading any bytecode. The codebase server would not 
>>>> execute any untrusted bytecode itself, only perform analysis using 
>>>> the ASM library, the aim would be that a codebase server was as 
>>>> secure as possible, such that it can be considered trustworthy and 
>>>> as impervious to attack as possible(existing denial of service 
>>>> attack strategies require consideration). One could even perform 
>>>> tests on codebases, by uploading deliberately malicious code and 
>>>> checking resulting analysis reports, or by occasionally confirming 
>>>> the analysis reports with other codebases or using a local codebase 
>>>> analysis processes. Separation of concerns.
>>>> Codebase Services would only be required to maintain a copy of the 
>>>> evolution bloodline for the latest binary backward compatible 
>>>> package. A package fork or breaking of backward compatibility would 
>>>> mean storing a copy of both of the latest divergent compatibility 
>>>> signatures, again some unchanged class subgroups may be shared 
>>>> between them. Java Bytecode versions (compiler specific) would also 
>>>> dictate which package version could be used safely in local JVM's.
>>>> Clients of services will have to accept a certain amount of 
>>>> downtime, once a particular instance of a package's classes are 
>>>> loaded into a classloader, no other compatible implementations of 
>>>> that package will be able to be loaded, this is only a problem for 
>>>> long lived service client processes. Object state will need to be 
>>>> persisted while the JVM restarts and reloads new bytecode 
>>>> (Serializable is also part of class API). This is due to the 
>>>> inability of an existing ClassLoader to reload classes (java debug 
>>>> excluded). Backward Binary compatibility doesn't necessarily infer 
>>>> forward compatibility, classes and interfaces can add methods 
>>>> without breaking compatibility with pre existing binaries, 
>>>> visibility can become more visible, abstract methods can become non 
>>>> abstract, even though some of these changes break source code 
>>>> compatibility, old clients aren't aware of the new methods and 
>>>> don't execute them. For specifics see Chapter 13, Binary 
>>>> Compatibility of the Java Language Specification, 3rd Edition, this 
>>>> is what I plan to base the compatibility analysis upon.
>>>> It would also be possible for services to utilise codebase servers 
>>>> in their classpath.
>>>> These issues I propose tackling are not simple obstacles, nor will 
>>>> they be easy to implement, some issues may even be intractable, but 
>>>> what the hell, who' with me? That's why we got into this in the 
>>>> first place isn't it? The challenge! Project Neuromancer 
>>>> highlighted areas for improvement, if we address some of these, I 
>>>> believe that River can become the much vaunted and dreamt of 
>>>> semantic web.
>>>> I want problems identified so solutions can be devised, lets see 
>>>> objections & supporting logic or better ideas.
>>>> Cheers,
>>>> Peter.

View raw message