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

From: Ron Monzillo <>
Date: Thu, 22 Aug 2013 18:04:33 -0400

On 8/22/13 1:11 PM, Raymond Auge wrote:
> 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.

Its unclear what the effect would be of enabling a container security
manager at some time after the point at which the
container had begun servicing application requests.

This is especially the case where the installation stores server keys
for use by the container. Once there
is some question as to whether the server might have been attacked by
code running in the server, it is
too late to put the cat back in the bag by turning on the security
manager. This is independent of
whether you need to restart in order to enable the security manager.

I don't have any reverence for the IS_SECURITY_ENABLED constant, but
conversely I don't put much stock in
the value of being able to enable the security manager on a system that
likely has already been compromised.

greater benefit and opportunity could likely be realized by assuming
that a security manager must be enabled,
and that there is need for some evolution in the security managers being
used by application servers.

> Sincerely,
> - 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 IS_SECURITY_ENABLED flag is a
>> 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é*
> <> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <> (@Liferay)