Jena GRDDL Reader: Version 0.3
Note: also refer to the security conformance page that ships in the doc directory of your version of the Jena GRDDL Reader.
Overview
The implementation of the security subsystem of the Jena GRDDL Reader is guided by the GRDDL Recommendation. However, this subsystem is incomplete. This page, indicates which parts of the security specification have been implemented, and to what extent.
Security considerations when using the Jena GRDDL Reader concern both the code itself, and the way in which the code is used. We start with things that the user of the code can do to minimize risks.
Some Limitations
A few key limitations of this software, detailed below are:
- No protection against denial of service attacks.
- No commitment to timely bug fixes.
- Some of the permitted read operations should, ideally, not be permitted.
- No division of local and network resources into security domains, or similar, is performed. Rather, read operations are permitted during imports and includes processing, and for GRDDL operations, and hopefully not otherwise. Such read operations, also allow writes to untrusted servers, by means of the URLs used during the read operations.
- The software has been developed almost exclusively by one person, rather than by a multi-skilled team.
- The security section of the specification was initially drafted by that person.
Note that GRDDL permits transforms to construct URLs that are then retrieved. In this way, any data accessed inappropriately can be transmitted to an untrusted server.
User Responsibilities
Reduced Privilege
The specification says:
are more safely executed with the privileges associated with an untrusted party, rather than the current user
When using the GRDDL Reader, it is best if the
process executing the code has as few privileges as possible.
In particular, the code should not run as the root
user under Unix. With other operating systems,
it is best to avoid running the code as a user with
administrator privileges.
Denial of Service
The specification says:
Software executing GRDDL transformations should provide appropriate mechanisms to abort processing after a reasonable amount of time has elapsed. In addition, GRDDL software should be limited to the consumption of only a reasonable amount of any given system resource.
The Jena GRDDL Reader does not implement such limitations. Hence, any use of this library should provide the end-user with the facility to interrupt. For example, using ctrl-C on a command line, to terminate the Java process.
Bug fixes
The specifcation says:
bugs may exist in some interpreters of a transformation language which might be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, no specific action is advised to take to prevent this aside from timely correction of such bugs as they are discovered
HP does not offer support contracts for the Jena GRDDL Reader and there is no commitment to timely correction of such bugs. It may be possible to purchase a support contract for the Saxon XSLT implementation. Please ask Saxonica Ltd.
The Jena GRDDL Reader currently has one engineer (Jeremy Carroll) assigned, part-time, to its development and support. There are no plans to increase this level of support. Jeremy Carroll has many other responsibilities and commitments that may detract from timely bug fixes to the GRDDL Reader.
As with all open source software, the final responsibility for timely bug fixes lies with the user community, who have access to the source code, to enable such fixes.
In any case, the end user needs to regularly check for updates of the major components used in the Jena GRDDL Reader. These include: Java, Jena, Saxon, and the Jena GRDDL Reader.
In particular, any Java bugfix release which is advised as addressing security issues for applets, may be required to fix security issues concerning the use of the Jena GRDDL Reader.
Partial Conformance Information
This section specifies the intent of the current version of the Jena GRDDL Reader in implementing the various security considerations raised in the specification.
Of course, each of these intents may not be correctly implemented. Such bugs would probably leave security holes.
Overview: Saxon and Sandboxing
The Jena GRDDL Reader uses the Saxon XSLT processor.
Some facilities provided by Saxon are used to improve
the security, in particular
net.sf.saxon.FeatureKeys.ALLOW_EXTERNAL_FUNCTIONS
is set to false; and
http://javax.xml.XMLConstants/feature/secure-processing
is set to true.
In addition, the Java SecurityManager
framework is used, so that each XSLT transform
is run on a separate thread, with reduced privileges.
Unfortunately, the author of this code (Jeremy Carroll),
had no experience of writing such sandboxing code, and
errors are to be expected.
Not 'off-the-shelf'
advised to guard against simply sending GRDDL transformations to "off-the-shelf" interpreters.
Secure processing options in Saxon are used.
Blocked dangerous URI Operations
In particular, operations to read or write URLs are more safely executed with the privileges associated with an untrusted party, rather than the current user.
During execution of XSLT transforms, nearly all URI operations are blocked by:
- Disabling the use of the URI resolver.
- Disabling the
<xsl:result-document>instruction - Disabling
the
unparsed-textandunparsed-text-availablefunctions.
Permitted dangerous URI operations
A variety of read URI operations are permitted.
These may allow untrusted code to access data that it should not be permitted to read.
These definitely allow untrusted code to send any information accessed illegally back to arbitrary servers on the Web.
XSLT code is compiled separately from its execution.
During compilation xsl:import
and xsl:include are enabled.
No attempt is made to reduce the privileges of
such operations.
The XML documents being processed may include references to other URIs, for instance as external entity references, or in an external DTD. In this release of the Jena GRDDL Reader, it is unclear whether or not such operations are permitted. This may be clarified in future releases.
The results of an XSLT transform are used as GRDDL results, which include URIs that are later dereferenced. No attempt is made to reduce the privileges of such operations.
Extensions and Native Java
Some transformation language implementations may provide facilities for loading and executing other programming language code. ... software executing GRDDL transformations should protect against such operators
and
Software executing GRDDL transformations should make sure that extensions are secure and do not present any kind of threat.
Most Saxon extensions to XSLT are switched off by using the secure processing flag.
Moreover, the use of the Java sandbox disables further insecure operations, which remain enabled: for example reading Java system properties.
Other Risks
Unreviewed Design and Code
Normal software development methodology suggests that both the design of the software and the code implementing the design should be reviewed by at least a second person.
This has not been done for this version of this software, which is almost exclusively the work of Jeremy Carroll.
Further Exposure to Errors in Carroll's Judgement
In addition, the author of this software, also drafted the initial version of the security aspects of the specification. This section has not had wide review. This further exposes this software to errors in his judgement.
