[javaee-spec users] Re: Position on SecurityManager/Policy SE APIs

From: Raymond Auge <>
Date: Thu, 22 Aug 2013 13:11:20 -0400

I'm actually not worried about Tomcat. I'm worried about the RI.

But I guess I have my answer. That's all I could expect.

- Ray

On Thu, Aug 22, 2013 at 1:05 PM, Ron Monzillo <>wrote:

> On 8/22/13 11:43 AM, Raymond Auge wrote:
> I think the point is being missed that I may want to implement some
> "component" which allows runtime management of SecurityManagers and/or
> Polcies, in collaboration with the "container" (i.e. having been granted
> permission to do so, which is also currently possible).
> However, it seems that due to the fact that one cannot reliably trust
> application code is honouring the state of these APIs means it's impossible.
> I don't see this discussion happening at that level.
> Seems like you are intent on being able to dynamically activate a security
> manager, and you are looking for some
> standard to say that Tomcat must let you do that from a typical web
> application.
> Java SE created dynamic APIs for a reason, so they could be leveraged by
> developers, so they might enable reactive security management, adjusting to
> changes and security demands in real time.
> It doesn't look to me like that is going to happen.
> Its also unclear how requirements in the EE platform spec will manifest in
> Tomcat.
> An important role of EE is to constrain or profile the use of the SE apis.
> Moreover, allowing an app to call setSecurityManager embodies
> more that just being able to enable the Tomcat or Glassfish
> SecurityManager, as
> it would allow replacement of the container's Security Manager with one of
> the caller's
> design.
> Application and information security is becoming a greater and greater
> concern and as I tweeted yesterday, it's currently impossible for a javaee
> platform system administrator to simply "enable" security in self
> defence if faced with an attack without tacking the system offline, even if
> offered the option to do so. Currently, the application will simply break!
> There certainly is room for more work in this area, and whether or not
> replacement is your intent,
> perhaps it would be more productive to focus on to whether it is and
> should be possible to replace
> a product's security manager.
> Ron
> Sincerely,
> - Ray
> On Thu, Aug 22, 2013 at 11:22 AM, Ron Monzillo <>wrote:
>> On 8/22/13 8:30 AM, Raymond Auge wrote:
>> Thank you Ron for your response.
>> Allow me to clarify further. And please if this is still not enough,
>> just ask.
>> The JSP RI (which is the forked Jasper implementation) contains the
>> following:
>> public static final boolean IS_SECURITY_ENABLED =
>> (System.getSecurityManager() != null);
>> While this seems to be innocuous enough what it really means is that no
>> consumer of that impl can rely on the SecurityManager API.
>> My first reaction was to file a bug report:
>> I also went to the original developers, the tomcat project developer
>> list, and asked for their position on the matter. The discussion was
>> quickly curtailed as "we don't support dynamic changes of the
>> SecurityManager". Understandable, since at this point tomcat's Jasper is a
>> "custom implementation" of the JSP spec.
>> Raymond,
>> I checked out your "Constants.IS_SECURITY_ENABLED", thread on the tomcat
>> developers list.
>> the EE 7 spec only requires that every product support running with a
>> security manager; it does not require that it be possible to dynamically
>> change this characteristic (presumably after the product has completed its
>> initialization). Also EE makes no requirement that a security manager (or
>> its effect, i.e., permission checking) be enabled for some apps, while not
>> for others. The security manager is a container feature, intended to
>> protect the container and os resources that the container process may
>> have access to from code (typically applications) running within the
>> container. There should be no expectation that applications that perform
>> internal permission checks will be able to enable the SecurityManager of
>> their hosting container. Moreover the security manager and permission
>> requirements of EE 7 cannot be presumed to be satisfied by Non EE 7
>> compatible web containers (of which I think Tomcat would be an example).
>> iow, and imo, Tomcat's support for running with a SecurityManager exists
>> independent of the EE 7
>> requirement to be able to do so, and Tomcat's internal reliance on its
>> Tomcat implementation detail.
>> that said, if an application depends on being able to perform
>> SecurityManager based permission checks, it will require a hosting
>> container in which the SecurityManager is enabled, and then I agree that
>> the hosting
>> hosting container should not interfere with the application's ability to
>> perform SecurityManager based permission checks according to the
>> recommended use pattern.
>> SecurityManager s = System.getSecurityManager();
>> (if (s != null) {
>> s.checkPermission(p);
>> }
>> Also, If the application learns that the security manager is not enabled,
>> it should not expect to be able to set a security manager for the
>> container. It might choose to initialize itself with reduced functionality
>> or to fail in its initialization. imv, the value of IS_SECURITY_ENABLED
>> must be consistent with that of (System.getSeucirtyManager() != null) since
>> the constant can have no effect on embedded permission checks in jvm
>> provided classes like sockets and it is likely that your app can
>> also rely on this consistency.
>> fwiw, if your app needs to perform permission checks in an environment
>> where you cannot rely on the security manager being enabled, then you might
>> want to consider making your checks by calling some other access control
>> api. Java also provides Policy.implies, or
>> AccessController.checkPermission.
>> HTH,
>> Ron
>> Therefore, I had hoped that at the Java EE specification level someone
>> may at least be inclined to offer a statement toward whether there is even
>> grounds for making such a bug report.
>> So my goal here is simply to identify whether there is some precedent,
>> charter of behaviour, set of rules, code of conduct, etc., by which the
>> Java EE specifications and their RIs are obliged to NOT break the
>> behaviours of the Java SE APIs upon which they are founded, even while not
>> containing or omitting specifics in their language or wording.
>> It seems to me that the RIs developed within Java EE should not take
>> liberties that custom implementations may afford to take since RIs tend to
>> be, by their nature, more portable and representative of best practices.
>> I hope that clarifies things.
>> Sincerely,
>> - Ray
>> On Wed, Aug 21, 2013 at 12:45 PM, Ron Monzillo <>wrote:
>>> On 8/21/13 11:31 AM, Raymond Auge wrote:
>>> Hello everyone,
>>> My name is Raymond Auge and this is my first email to the list.
>>> Hopefully I follow proper protocol. Please let me know if I have not.
>>> -----
>>> Sorry, my question may seem odd.
>>> I would like to get an official position statement on the handling of
>>> the SecurityManager/Policy APIs with respect to Java EE?
>>> I suppose I am asking:
>>> "Is it OK for Java EE specifications/implementations to make
>>> assumptions about the state of the SecurityManager/Policy without
>>> respecting changes in their runtime state?"
>>> If you think there is an issue with the specifications, it would help
>>> if you could provide a reference to the
>>> specification content.
>>> that said, a perhaps overly simplistic answer to your question, is that
>>> EE 7 requires that every EE product be able to run with a security manager
>>> enabled. So for example, it would not be appropriate for an implementation
>>> to assume that a security manager will not (or at least never) be enabled.
>>> For prior releases of EE, one might conclude otherwise.
>>> Regarding the runtime or installation specific state of access control
>>> Policy (as enforced by the Policy system) there is an expectation that the
>>> Policy implementation enforce the policy as configured for the
>>> installation, with the additional requirement that every EE product provide
>>> a means for applications to be granted some specific permissions identified
>>> in the EE specification.
>>> EE 7 also added a new facility by which applications may declare the
>>> permissions that they require.
>>> I'll stop there for now,
>>> Ron
>>> --
>>> *Raymond Augé* <>
>>> (@rotty3000)
>>> Senior Software Architect
>>> *Liferay, Inc.* <> (@Liferay)
>> --
>> *Raymond Augé* <>
>> (@rotty3000)
>> Senior Software Architect
>> *Liferay, Inc.* <> (@Liferay)
> --
> *Raymond Augé* <>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <> (@Liferay)

*Raymond Augé* <>
Senior Software Architect
*Liferay, Inc.* <> (@Liferay)