From mark.reinhold at oracle.com Wed Apr 1 15:58:57 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Apr 2015 08:58:57 -0700 Subject: Module-system requirements, draft 2 In-Reply-To: References: <20150325225212.B8AB0534D7@eggemoggin.niobe.net>, Message-ID: <20150401085857.608727@eggemoggin.niobe.net> 2015/3/31 6:57 -0700, tim_ellison at uk.ibm.com: > Last few comments: > > (a) Just to ensure this is not misinterpreted, perhaps consider rephrasing > > | - _Protection domains_ --- At run time it must be possible to associate > | the code in modules with protection domains, for the purpose of > | granting security permissions. > > as > > - _Protection domains_ --- At run time it must be possible to associate > modules with protection domains, for the purpose of granting security > permissions to code in those modules. The existing wording is intentional, to allow for an approach (as we discussed) that's based on associating class loaders with protection domains rather than mandate an extension of the protection-domain concept to associate specific modules with protection domains. The former approach is simpler and may be adequate, but the latter is not ruled out. > (b) > | - _Non-prescriptive version strings_ --- Version strings must have a > | precisely-defined syntax and be totally ordered, but otherwise their > | format should be as general as possible in order to accommodate > | existing popular version-string schemes. > > > I'm trying to reconcile the requirement for version strings to be > "non-prescriptive" and have a "precisely-defined syntax". The need > for a defined syntax is not reflected elsewhere, so is it sufficient > that they are simply totally ordered, and otherwise left to the needs > of the configuration management systems that assemble coherent sets of > modules? Yes -- that's exactly what this requirement is trying to capture. To define a total order requires a precise syntax, but otherwise the specification shouldn't force a specific interpretation of version strings. > (c) This version doesn't incorporate the "Overrideable encapsulation" > requirement described here > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-February/000020.html Good catch -- I'll add that in the final version. > or the clarification suggested for _Referential integrity_ to read > "that each module can be configured only to reference" rather than > "each module can only be configured to reference" Will fix. - Mark From niftiness at gmail.com Thu Apr 2 06:23:07 2015 From: niftiness at gmail.com (Tim Boudreau) Date: Thu, 2 Apr 2015 02:23:07 -0400 Subject: Module-system requirements, draft 2 In-Reply-To: <20150401085857.608727@eggemoggin.niobe.net> References: <20150325225212.B8AB0534D7@eggemoggin.niobe.net> <20150401085857.608727@eggemoggin.niobe.net> Message-ID: On Wed, Apr 1, 2015 at 11:58 AM, wrote: > 2015/3/31 6:57 -0700, tim_ellison at uk.ibm.com: > > Last few comments: > > > > (a) Just to ensure this is not misinterpreted, perhaps consider > rephrasing > > > > | - _Protection domains_ --- At run time it must be possible to > associate > > | the code in modules with protection domains, for the purpose of > > | granting security permissions. > > > > as > > > > - _Protection domains_ --- At run time it must be possible to associate > > modules with protection domains, for the purpose of granting security > > permissions to code in those modules. > > The existing wording is intentional, to allow for an approach (as we > discussed) that's based on associating class loaders with protection > domains rather than mandate an extension of the protection-domain > concept to associate specific modules with protection domains. The > former approach is simpler and may be adequate, but the latter is > not ruled out. > > > (b) > > | - _Non-prescriptive version strings_ --- Version strings must have a > > | precisely-defined syntax and be totally ordered, but otherwise their > > | format should be as general as possible in order to accommodate > > | existing popular version-string schemes. > > > > > > I'm trying to reconcile the requirement for version strings to be > > "non-prescriptive" and have a "precisely-defined syntax". The need > > for a defined syntax is not reflected elsewhere, so is it sufficient > > that they are simply totally ordered, and otherwise left to the needs > > of the configuration management systems that assemble coherent sets of > > modules? > > Yes -- that's exactly what this requirement is trying to capture. > To define a total order requires a precise syntax, but otherwise the > specification shouldn't force a specific interpretation of version > strings. > I wonder if "total order" is actually too strong a statement. I think in the extremely long run, arbitrary version numbers invented by fallible humans may become attractive, while commit-hashes from SCMs such as git or hg have a number of desirable attributes: - The exact state of the source tree is recoverable from a hash - Assuming the compilation environment includes enough metadata to reconstruct it, this can act as a very-expensive-to-compute HMAC - you can determine if the bits you received are an exact match for the bits you build (modulo a bunch of things that could break that) I can imagine a versioning scheme which used partial order - Instead of 1.0, bae62770d3ba Instead of 1.1, bae62770d3ba / d452b222d78 Instead of 1.2, bae62770d3ba / d452b222d78 / 3c4a81666a4 Instead of 1.3, bae62770d3ba / d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb Instead of 1.4, d452b222d78 / 3c4a81666a4 / 3ec0e3bb788cb / 79792b0779 such that determining if 1.3 is newer than 1.1 is still a fast test (scan left to the first common known ancestor hash), but in fact, given two disjoint version strings, total order cannot be determined (some threshold number of parent hashes are required so as to make this a non-problem unless you don't upgrade libraries for a decade, but which can be solved by acquiring an intermediate version that overlaps the other two, or acquiring all known versions and topologically sorting them). I realize that's a bit hypothetical, but we have today the ability to generate far more reliable (if less intuitive) version strings than arbitrary dewey-decimal. So the point I'm trying to make is that you don't actually need total order to answer this-comes-after-that questions, so perhaps we don't want to insist on it. -Tim From hearn at vinumeris.com Thu Apr 9 11:04:06 2015 From: hearn at vinumeris.com (Mike Hearn) Date: Thu, 9 Apr 2015 13:04:06 +0200 Subject: Use case for security managers/protection domains Message-ID: Hello, I noted that last month there was a brief discussion on security re: modules, and Mark mentioned he didn't know of any compelling use cases for the JDK security/permissions model outside of stuff like sandboxing applets and the like. Recently I've been pondering and researching a new use case for Java style security management, which is to reduce code audit overheads for very security sensitive apps. In particular, I work in the Bitcoin community, and we are writing apps ("wallets") which control potentially large sums of money and can move that money more or less instantly and irreversibly. This fact makes attacking wallets by subverting the software development process itself a potential problem. Of course, whilst this issue is taxing the Bitcoin world first, it is really an issue for any kind of cryptographic app that controls important information. So I've been research ways to fix this. One way is to have multi-signature software updates. I've written a simple online update engine called UpdateFX for javapackager-based JavaFX apps. The idea is multiple developers all read the code commits since the last release, compile the software from git head and verify they got the same JAR out, and then sign it, and the update mechanism verifies that multiple signatures are present. A single compromised developer cannot break the system. The problem is that this only works when the software is fairly slow moving. Otherwise developers find themselves in a bind: they must potentially audit every line of code that is changed between every release to detect an attempt to insert a back door. Including in dependent libraries. This does not scale. Java permissions to the rescue! A high security app can structure itself with internal sandboxes around its sub-components. If the app "kernel" manages the encryption keys and performs risk analysis or user confirmations but little else, the rest of the app can be subjected to less aggressive auditing. Potentially, the multi-signature requirement can be relaxed for submodules. This would be ideal: the high security of an audited, multi-signed app can be combned with the rapid iteration typical of web apps. I recognise that this is not an especially compelling use case* today* because not many apps work this way. But I hope we will see it become more common in future. Java 8 and JavaFX in particular are seeing some adoption in the Bitcoin community because HTML5 doesn't really provide what we need to build decentralised, secure applications. The flexible security model is a cherry on top that we will hopefully start eating in the next 18-24 months. thanks, -mike