Hi, On 4/8/22 11:13 AM, Sean Mullan wrote: > In general, I think authorization is best done at a higher layer within > the application and not via low-level SM callouts. Authorize the subject > first and if not acceptable, prevent the operation or API from being > called in the first place. Once the operation is in motion, you have > already taken a greater risk that something might go wrong.
I completely agree with this vision, and also agree with the other arguments that both Sean Mullan and Andrew Dinn mentioned before in this thread. 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. 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. Best, Martin.-
