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 Sun, 20 Sep 2009 05:30:00 GMT
In the paper below, Mirrors are metadata objects that represent class 
file api, ie method signatures, field signatures...

The author states they use BCEL, to perform the static bytecode 
analysis, we're using ASM.  If a code base is trusted by a client, the 
overhead that ISOMOD (A modular isolation framework) is subject to 
during class loading, could be almost entirely avoided by analysis and 
construction of the mirror objects at the code base.

This would allow a code base service to upload untrusted bytecode, 
analyse it, produce the mirror object tree's  and provide these to a 
trusting client, the client would need to be aware that the code was not 
fully trusted. Trusted package authors uploading jar files to a 
codebase, would need to create access policy's for untrusted code / 
packages to be enforced by clients during class loading and class name 

I suspect the authors use inheritance to provide a "view" of the 
original class file, passing the "view" during class resolution, this 
imposes limits on what methods can be hidden from another namespace:

    * Classes must be public or package-private.
    * Classes must be non-final
    * Methods must be public, package-private or protected
    * Methods must be non-final

A class "view" isn't required when hiding the entire class, only for 

Trying to create access policies for working with untrusted code base 
services doesn't seem to be worthwhile, it would increase the local 
class loading processing overhead, since analysis would have to be 
performed locally by the client.   It would probably be best to simply 
revert to the applet model of isolation.

I think initially I'll try implementing policies without constraints on 
method visibility,  that can wait until later.

Peter Firmstone wrote:
> The comments on security below are based on this research paper:
> http://pages.cpsc.ucalgary.ca/~pwlfong/Pub/fong-orr-2009-manuscript.pdf
> 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 ;)
> Cheers,
> Peter.
> 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 
> mechanism.
> 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