On Fri, Apr 22, 2022 at 10:04 PM Martin Balao <mba...@redhat.com> wrote: > In my view, authorization decisions at higher layer generally > have better context, are more clear and less riskier. At a lower layer > there is more complexity and chances of both subtle combinations or > unseen paths that may lead to check bypasses. I lean towards not > splitting authorization responsibility through different layers, which > might create confusion or even a false sense of security in some cases. > To illustrate with a trivial example, if a subject is not supposed to > access to some information, it's the application that has enough context > to decide and block right away. Letting the attempt go though the call > stack down to the network or the file system might be the recipe for > missing a channel.
The point of the proposal is to allow checks at system-level operations _in addition to_ application-level operations. It sounds like you are saying that adding the extra authorization check is somehow less secure? I'm not sure I agree with that reasoning. > I won't enter the untrusted code case -which has been extensively > discussed already- but want to briefly mention something about the > "trusted code performing risky operations" case. My first point is that > vulnerabilities at the JVM level (i.e.: memory safety compromises) are > serious enough to potentially bypass a SecurityManager. My second point > is that the SecurityManager is really unable to deal with tainted data > flowing from low to high integrity domains, and sanitation must be > performed by the application or the library anyways because there are > infinite ways in which it can be harmful. Even when the data is obtained > at a low integrity domain, there will be a flow towards a high integrity > domain to perform a legitimate action (i.e.: SQL query, OS command > execution, etc). The OS and the DB engine, in this example, have the > knowledge, granularity and power to be the next level of enforcement > after data sanitation. Again, I wouldn't split this responsibility or > pass it to the JDK for the same reasons than before. Nothing in the proposal causes splitting or delegation of responsibilities. It is _only_ about preserving security checkpoints in the JDK, which *add* a layer of checks to what the container might already provide. Nothing is being subtracted, and thus I find it hard to accept that preserving these checks somehow reduces security overall. In absolute terms, using a security manager (even with all of its problems) is *more* secure than not using it on the same code base and deployment. I'm not sure how this can be rationally refuted. The proposal is about retaining this incremental increase in security, while both adjusting the user's expectations via documentation *and* significantly reducing the burden of CVEs and maintenance on the JDK itself (and putting it on to the third party authorization framework), which in my estimation is the *real* stakes here. Nothing in the proposal is intended to solve the issue of tainted data; with or without this proposal, this is an unsolved problem. -- - DML • he/him
