You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Dan Becker <da...@gmail.com> on 2008/05/02 16:29:38 UTC
More Java security fixes on the way
FYI, so every one is aware of recent Tuscany security changes and for
your comments. Over the last few weeks I have been making fixes to the
Tuscany core in order to make the code a bit safer with Java 2 security
enabled. There are many instances in which we want Tuscany code to
perform some privileged action (such as read a system property or write
a file to the file system), yet we do not want client code to have this
ability.
There are over 300 Tuscany calls to privileged Java APIs which may throw
some sort of security exception if proper access is not granted. Since
there are so many APIs, I have have been issuing patches in smaller
increments. This makes the patch easier to review, commit, and reverse
if there is a problem.
Following is a list of past changes related to security.
TUSCANY-2108 - Enabled Simple Calculator to run with security on
TUSCANY-2227 - Enabled ITests to run with secuirty on
TUSCANY-2030 - Enabled Simple Caclulator to run on WebSphere
Expect a few JIRAs in the next weeks to enable the demos, samples, and
vtests to run with security on. And then I would like to make a maven
profile that allows a user to test with security on or off.
If you have any other ideas related to Java 2 security, I encourage you
to mention them here.
--
Thanks, Dan Becker
Re: More Java security fixes on the way
Posted by Dan Becker <da...@gmail.com>.
> Raymond Feng wrote:
>I have some trouble applying the patch. It complains an unknown line
>type is found line 573 (I don't know what it means:-(.
Hi Raymond. I regenerated the patch as TUSCANY-2290.2.patch and attached
it to the TUSCANY-2290 JIRA. I think with the previous patch I deleted
some non-security changes, and I might have corrupted the file.
Hopefully this one is better, let me know.
--
Thanks, Dan Becker
Re: More Java security fixes on the way
Posted by Raymond Feng <en...@gmail.com>.
Hi, Dan.
I have some trouble applying the patch. It complains an unknown line type is
found line 573 (I don't know what it means:-(.
Thanks,
Raymond
--------------------------------------------------
From: "Dan Becker" <da...@gmail.com>
Sent: Friday, May 16, 2008 9:31 AM
To: <tu...@ws.apache.org>
Subject: Re: More Java security fixes on the way
> Jean-Sebastien Delfino wrote:
>> I'd like to suggest the following:
>> - Keep the Java2 security blocks in test case classes
>> - Don't put them in sample program classes
>>
>> Hmmm but looking at these test cases, could you help me understand why we
>> need these technical API calls to the jmsBroker at all?
>>
>> Isn't SCA supposed to shield me from having to deal with that kind of
>> calls?
>
> Based on the several opinions, I've regenerated the patch so that samples
> are keep simple and do not have security code in them.
>
> Jean-Sebastien, I can't comment on why several of the samples have
> explicit JMS broker starts and stops in their JUnit tests as I am not the
> original author. It seems like the author wanted to ensure the broker was
> running before running the unit test. However, commenting out the
> startBroker call in sample-helloworld-ws-service-jms, the JUnit test still
> ran and passed.
>
> --
> Thanks, Dan Becker
Re: More Java security fixes on the way
Posted by Dan Becker <da...@gmail.com>.
Jean-Sebastien Delfino wrote:
> I'd like to suggest the following:
> - Keep the Java2 security blocks in test case classes
> - Don't put them in sample program classes
>
> Hmmm but looking at these test cases, could you help me understand why
> we need these technical API calls to the jmsBroker at all?
>
> Isn't SCA supposed to shield me from having to deal with that kind of
> calls?
Based on the several opinions, I've regenerated the patch so that
samples are keep simple and do not have security code in them.
Jean-Sebastien, I can't comment on why several of the samples have
explicit JMS broker starts and stops in their JUnit tests as I am not
the original author. It seems like the author wanted to ensure the
broker was running before running the unit test. However, commenting out
the startBroker call in sample-helloworld-ws-service-jms, the JUnit test
still ran and passed.
--
Thanks, Dan Becker
Re: More Java security fixes on the way
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Dan Becker wrote:
> Raymond Feng wrote:
>> I'm looking into the patch you contributed with
>> https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue
>> catching my eyes. We have samples in Tuscany today which use some
>> technology APIs, for example, to start the ActiveMQ JMS broker. To run
>> these samples with Java2 security enabled, we have to surround some of
>> the calls with privileged block. That seems to complicate/pollute the
>> samples. Should we leave these samples as-is without supporting Java2
>> security (or grant permissions to the sample code directly with a
>> policy file)?
>
> Hi Raymond,
>
> Thanks for the code review. Those are excellent points you bring up
> which not only apply to the Tuscany-provided samples, but potentially
> also to user-solutions which exploit Tuscany as the samples do. Do you
> require such code to implement security blocks (and grant permissions
> with policy files) or do you simplify and not support security?
>
> In my opinion, the answer would depend on what you would expect the user
> to do and what the purpose of the user code would be. For instance with
> application level code and samples I would never expect the user to have
> to add privileged blocks or add security policy permissions. On the
> other hand, for extensions and code that used Tuscany SPIs, I would
> expect requirements for the extension to provide privileged blocks and
> security policy permissions.
>
> In the current situation you mention (starting the ActiveMQ JMS broker),
> I agree it does complicate the samples. But any user application that
> attempts to start the JMS broker and support Java 2 security would have
> to do the same thing. I am fine removing the complicating security code
> from the sample, but then I should write a wiki page or other
> documentation that shows how to support this.
>
> Other opinions?
>
I'd like to suggest the following:
- Keep the Java2 security blocks in test case classes
- Don't put them in sample program classes
Hmmm but looking at these test cases, could you help me understand why
we need these technical API calls to the jmsBroker at all?
Isn't SCA supposed to shield me from having to deal with that kind of
calls?
--
Jean-Sebastien
Re: More Java security fixes on the way
Posted by Dan Becker <da...@gmail.com>.
Raymond Feng wrote:
> I'm looking into the patch you contributed with
> https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue
> catching my eyes. We have samples in Tuscany today which use some
> technology APIs, for example, to start the ActiveMQ JMS broker. To run
> these samples with Java2 security enabled, we have to surround some of
> the calls with privileged block. That seems to complicate/pollute the
> samples. Should we leave these samples as-is without supporting Java2
> security (or grant permissions to the sample code directly with a policy
> file)?
Hi Raymond,
Thanks for the code review. Those are excellent points you bring up
which not only apply to the Tuscany-provided samples, but potentially
also to user-solutions which exploit Tuscany as the samples do. Do you
require such code to implement security blocks (and grant permissions
with policy files) or do you simplify and not support security?
In my opinion, the answer would depend on what you would expect the user
to do and what the purpose of the user code would be. For instance with
application level code and samples I would never expect the user to have
to add privileged blocks or add security policy permissions. On the
other hand, for extensions and code that used Tuscany SPIs, I would
expect requirements for the extension to provide privileged blocks and
security policy permissions.
In the current situation you mention (starting the ActiveMQ JMS broker),
I agree it does complicate the samples. But any user application that
attempts to start the JMS broker and support Java 2 security would have
to do the same thing. I am fine removing the complicating security code
from the sample, but then I should write a wiki page or other
documentation that shows how to support this.
Other opinions?
--
Thanks, Dan Becker
Re: More Java security fixes on the way
Posted by Raymond Feng <en...@gmail.com>.
Hi, Dan.
I'm looking into the patch you contributed with
https://issues.apache.org/jira/browse/TUSCANY-2290. There is one issue
catching my eyes. We have samples in Tuscany today which use some technology
APIs, for example, to start the ActiveMQ JMS broker. To run these samples
with Java2 security enabled, we have to surround some of the calls with
privileged block. That seems to complicate/pollute the samples. Should we
leave these samples as-is without supporting Java2 security (or grant
permissions to the sample code directly with a policy file)?
Thanks,
Raymond
--------------------------------------------------
From: "Dan Becker" <da...@gmail.com>
Sent: Friday, May 02, 2008 7:29 AM
To: "tuscany-dev" <tu...@ws.apache.org>
Subject: More Java security fixes on the way
> FYI, so every one is aware of recent Tuscany security changes and for your
> comments. Over the last few weeks I have been making fixes to the Tuscany
> core in order to make the code a bit safer with Java 2 security enabled.
> There are many instances in which we want Tuscany code to perform some
> privileged action (such as read a system property or write a file to the
> file system), yet we do not want client code to have this ability.
>
> There are over 300 Tuscany calls to privileged Java APIs which may throw
> some sort of security exception if proper access is not granted. Since
> there are so many APIs, I have have been issuing patches in smaller
> increments. This makes the patch easier to review, commit, and reverse if
> there is a problem.
>
> Following is a list of past changes related to security.
> TUSCANY-2108 - Enabled Simple Calculator to run with security on
> TUSCANY-2227 - Enabled ITests to run with secuirty on
> TUSCANY-2030 - Enabled Simple Caclulator to run on WebSphere
>
> Expect a few JIRAs in the next weeks to enable the demos, samples, and
> vtests to run with security on. And then I would like to make a maven
> profile that allows a user to test with security on or off.
>
> If you have any other ideas related to Java 2 security, I encourage you to
> mention them here.
>
> --
> Thanks, Dan Becker