From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; To: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Monday, March 4, 2013 7:36:58 AM Subject: [jboss-as7-dev] About the getSecurityManager() optimization We have, in our core code and frameworks, a few chunks of code like this: if (getSecurityManager() == null) { doSomePrivilegedThing(); } else { AccessController.doPrivileged(new PrivilegedThingAction()); } The idea is that doPrivileged and the action GC load is a cost we should not pay if there's no security manager. There is a potential problem here though. It is possible to install a security manager after the server is started. While this may sound like an odd thing to do, we know that at least one third-party library does in fact install a security manager if you don't prevent it from doing so. Furthermore, as we're required to support running under a security manager, we were talking about allowing the subsystem to install a security manager during extension init instead of requiring it to be sent in to the command at boot. The problem is that if you set a security manager during the window between when the presence of a security manager is checked for, and when the privileged action runs, you run the risk of getting a random SecurityException. We'll call this problem "the SM race". It seems to me that we have a few options for supporting running under a security manager: 1) Require it to be specified at boot (pass -secmgr to JBoss Modules in the start script) 2) Let it be set by a security manager subsystem 3) Just run with a security manager at all times Only #1 would allow the above optimization to work, and that's only if nobody else sets a security manager in the meantime. Given that fact, coupled with the observation that running under a security manager does not appear to significantly impact server boot time, I'm wondering if we should get rid of this optimization wherever it appears and just always use doPrivileged. Maybe once we see what kind of time impact -secmgr has on the test suite, we'll know whether this is a reasonable course of action (I would expect the performance impact to be somewhere between running with and without a security manager for the non-SM case, and of course no impact for the SM case). -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; To: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Monday, March 4, 2013 8:03:40 AM Subject: Re: [jboss-as7-dev] About the getSecurityManager() optimization I'm definitely interested in getting some real idea as to the runtime cost of (a) these checks and (b) running under a secmgr. I know for sure that (b) is nowhere near as great as I expected (though obviously not free), due in part possibly to the Modules<->SM integration code and Policy implementation which (I believe) enables certain fast-path optimizations within AccessController. I would also couple that outstanding question with my observation, based on analyzing (and refactoring) all 300+ privileged blocks in the AS codebase, that none of them are in request fast paths, apart from the privileged action interceptors I just wrote (which would only be used to replace the (theoretically) similarly expensive existing security interceptors). Overall I'd want to see hard numbers before I worry too much. As far as SPECj goes, if it requires an EE-certified server configuration then it may have to run under a security manager no matter what (this configuration is required to be supported by EE 7 and might in turn be required for apples-to-apples comparison with other servers). In this case it's no longer a question of "do we do this optimization" and more a question of "how can we make this as efficient as possible", which IMO we should be asking anyway. Based on the analysis I've done so far, I suspect the greater cost of these doPrivileged calls is one-time class init and general GC load, both of which I've mitigated really a lot in my security-utils patch which removed hundreds of anonymous inner classes and replaced a bunch of action objects with a handful of singletons. And I don't think we're at the end of what we can do to improve things on this front either. On 03/04/2013 08:49 AM, Andrig Miller wrote: > This concerns me where our SPECjEnterprise2010 benchmarking efforts > are concerned. > > At this point, we cannot afford anything that could degrade > throughput and/or increase CPU utilization. > > Andy > > ----- Original Message ----- >> From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; >> To: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; >> Sent: Monday, March 4, 2013 7:36:58 AM >> Subject: [jboss-as7-dev] About the getSecurityManager() >> optimization >> >> We have, in our core code and frameworks, a few chunks of code >> like >> this: >> >> if (getSecurityManager() == null) { >> doSomePrivilegedThing(); >> } else { >> AccessController.doPrivileged(new PrivilegedThingAction()); >> } >> >> The idea is that doPrivileged and the action GC load is a cost we >> should >> not pay if there's no security manager. >> >> There is a potential problem here though. It is possible to >> install >> a >> security manager after the server is started. While this may >> sound >> like >> an odd thing to do, we know that at least one third-party library >> does >> in fact install a security manager if you don't prevent it from >> doing >> so. Furthermore, as we're required to support running under a >> security >> manager, we were talking about allowing the subsystem to install a >> security manager during extension init instead of requiring it to >> be >> sent in to the command at boot. >> >> The problem is that if you set a security manager during the >> window >> between when the presence of a security manager is checked for, >> and >> when >> the privileged action runs, you run the risk of getting a random >> SecurityException. We'll call this problem "the SM race". >> >> It seems to me that we have a few options for supporting running >> under a >> security manager: >> >> 1) Require it to be specified at boot (pass -secmgr to JBoss >> Modules >> in >> the start script) >> 2) Let it be set by a security manager subsystem >> 3) Just run with a security manager at all times >> >> Only #1 would allow the above optimization to work, and that's >> only >> if >> nobody else sets a security manager in the meantime. >> >> Given that fact, coupled with the observation that running under a >> security manager does not appear to significantly impact server >> boot >> time, I'm wondering if we should get rid of this optimization >> wherever >> it appears and just always use doPrivileged. >> >> Maybe once we see what kind of time impact -secmgr has on the test >> suite, we'll know whether this is a reasonable course of action (I >> would >> expect the performance impact to be somewhere between running with >> and >> without a security manager for the non-SM case, and of course no >> impact >> for the SM case). >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

The reason why we had package level securityactions/privileged blocks was mainly to provision the permissions down to the package level (if need be). Having singleton classes representing priv blocks may be ok for AS core code. However, how do we prevent applications from using these singleton priv blocks?

On 3/4/13 9:40 AM, David M. Lloyd wrote: > On 03/04/2013 09:35 AM, Anil Saldhana wrote: >> The reason why we had package level securityactions/privileged blocks >> was mainly to provision the permissions down to the package level (if >> need be). Having singleton classes representing priv blocks may be ok >> for AS core code. However, how do we prevent applications from using these >> singleton priv blocks? > > No need to do so - the application still has to use doPrivileged from > their own code base. All we do is provide an object to give to it, to > avoid redundant classes from being defined and object instances from > being created. IOW there's no security risk that didn't already exist. > > That said, this API is private (aka not supported by us for external > use), so we're free to change it or remove it at any time if we need to. > BTW, there's some useful stuff in the old jboss-common-core for this area, particular for system properties and TCCL changes. The gist of it was the caller would request an instance of a utility class in a privileged block and the necessary permission checks would be performed during construction of the instance. The caller could then cache the utility object and reuse. This eliminates the redundant privileged blocks and package protected SecurityActions classes we have. See for example org.jboss.util.loading.ContextClassLoader and ContextClassLoaderSwitcher. I found the latter most useful, since a typical TCCL manipulation involves 3 actions, a get, a set and another set to restore in a finally block. The caller of course has to be careful not to let the cached security util instance leak.