I guess I can't fault that logic.
Thanks for your time Ron.
Sincerely,
- Ray
On Thu, Aug 22, 2013 at 6:04 PM, Ron Monzillo <ron.monzillo_at_oracle.com>wrote:
> 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.
>
> Ray,
>
> 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.
>
>
> Ron
>
>
> Sincerely,
> - Ray
>
>
> On Thu, Aug 22, 2013 at 1:05 PM, Ron Monzillo <ron.monzillo_at_oracle.com>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 <ron.monzillo_at_oracle.com>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:
>>> https://java.net/jira/browse/JSP-37
>>>
>>> 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 files...so 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 <ron.monzillo_at_oracle.com>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é* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect
>>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect
>>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>>
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect
>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)