> On Jul 2, 2019, at 11:58 AM, Juan José Ramos <jra...@pivotal.io> wrote:
>
> Hello Jake,
>
> I've been doing some reading about the *Java Security Manager* and, even
> when it might work for our use case, I don't think is a good fit due to the
> following reasons:
> 1). We already have chosen *Shiro* for authentication and authorization,
> adding yet another security framework (and mapping between roles and
> permissions between the two of them) for OQL method invocation security
> seems overkilling to me. I'd rather spend some time improving the
> *ResourcePermissionBasedMethodAuthorizer
The security manager doesn’t have to be as fined grained as individual users.
Do we really intend to support actions on objects base on current user too?
> [1] *and/or adding *Permissions*/*Roles* to our current security framework
> than introducing a new security framework altogether.
Again, we don’t have to add anything. If the user wants to restrict access to
certain activities they could add a policy file to the JVM to do so. It doesn’t
have to be user based. We could simply have two hard coded roles, UserCode and
SystemCode. SystemCode has AllPermissions, UserCode has none. Now we run all
queries under the context of UserCode and it can’t execute any File, Runtime,
Socket, etc.
> 2). There can only be one *Security Manager* per JVM at a given time
Eh, sorta but no, you can use thread contexts and class loader isolation, but
there really doesn’t need to be more than one.
.
> 3). Customers already using a custom *Security Manager* on their own will
> be in trouble... we can certainly wrote our own implementation as a
> composite and parse multiple policy files, but this will probably break the
> backward compatibility for these customers (and requires yet more
> configuration and things to keep in mind when upgrading).
Their custom SecurityManager would conform to the same rules as the default
file based one in the JRE. They would be able to control code access using
their existing framework. Seems like win to me.
> 4). The current set of default *Permissions* (*PropertyPermission*,
> *FilePermission*, etc.) don't apply to our use case, so we'll need to
> create our own implementations and do some plumbing to map to what we
> currently have in terms of principals and roles (more boilerplate).
How do they not apply?
> 5). In order to check a permission we basically need to check whether a
> Security Manager is installed (*System.getSecurityManager() != null*) and
> execute the check afterwards (*securityManager**.checkPermission(perm)*);
> the *Security Manager* then looks at the classes of all methods currently
> within the call stack (roughly speaking) and returns or throws an
> exception... a lookup through a simple Map is probably faster, and easier
> to maintain and read.
All the things we need to be protected from have already been coded with these
checks in the JRE. Do you think we need to protect other activities?
-Jake
