Thanks for responding Peter, I've commented inline below. On Tue, Apr 5, 2022 at 8:19 PM Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > Thanks David, > > I'd certainly support such a proposal and encourage OpenJDK to consider > exploring it. > > Perhaps also consider; no privileges should be granted unless a > privileged call is made, this simplifies the the stack walk, such that > it's only required when a privileged call is made.
I think this is a reasonable requirement for an implementation. If we move forward with this however, the proposal would explicitly not specify how privileges are established or propagated; that would be implementation-defined. > With a policy tool that generates policy files, it allows the developer > to turn off all features that are not required, which improves security. Policy is specifically excluded from the proposal and would be implementation-defined. This should grant significantly more flexibility to meet the authorization needs of the end user. For example, one implementation could be designed to perform authorization checks based on the call stack, like AccessController does today. Another implementation might authorize based on an authenticated user identity and not be concerned with the call stack at all. Other implementations might do both. > Something that bothered me about SocketPermission was that it didn't > allow granting permission to subnets, or ranges of IP addresses. > > It always bothered me that data parsing isn't controlled with permissions. > > For data parsing the remote authenticated subject represents the source > of the data, if the data source cannot be authenticated, then data > cannot be parsed. Of course when parsing is done it needs to be > validated, but authentication goes a long way to filtering out potential > attack vectors. By removing the bulk of the specification from the JDK, the implementation is more free to define how permissions are granted and checked (for example, by authorizing by CIDR ranges rather than by single addresses). Both proposal options would allow for the possibility of adding more authorization checks in the future in a reasonably backwards compatible way, though I think in practice it is unlikely (except maybe in the context of new features that might benefit from such checks). The reason that this is a "proposal to propose" rather than an actual proposal is because we ourselves do not have a clear answer as to whether the costs even of this simplified compromise solution are low enough, compared to the expected value return, to justify the work necessary to produce a formal proposal and prototype. If the upstream consensus is "no, we're not likely to approve this", we're going to consider having to plead our case when we decide whether we want to devote that effort as an additional cost. And we really do have to balance cost and benefit *to us* as well as to the OpenJDK team. When suggesting new features it's always tempting to try and "boil the ocean", especially when inspiration strikes and one is tempted to incorporate dozens of new and interesting ideas. But in this particular case, the real benefit comes from figuring out what we can *remove* versus what must be kept: the more we can remove, the simpler the change would be, and the more likely it will be that we can justify the labor involved in making the change - and, I think, the more likely that the proposal would be palatable to the upstream OpenJDK maintainers. As a final note, I don't think that any context-based authorization based system would really suffice for handling tainted data, unfortunately. For some languages, tainted data is handled at a language level. We would not set out to solve that problem with this proposal, though I think we would all agree that this is a real problem and I think it's safe to speculate that Red Hat would likely be in favor of any effort to tackle it. -- - DML • he/him
