RE: Need help with SecurityManager and errors thrown by JT400 classIFSFile

Hey Charles!

I agree with you. But the security folks here don't care if their tests
interfere with production and they don't warn operations when they test.
When something crashes we pick up the pieces and if we see an unfamiliar
IP address we ask security if it was them. Sad.

I'd assume your desktops use DHCP, which means the IPs could change!

SecurityManger can help you there because it takes either an IP address
or a host name. Fortunately our DNS resolves the names assigned to our
computer so I can use the name of my laptop instead of it's IP address
this week.

Thanks for you observations!
Bill

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, June 25, 2009 3:07 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Need help with SecurityManager and errors thrown by JT400
classIFSFile

Bill,

Unless there's something super sensitive about the application, allowing
any
connection from the internal network seems reasonable. Not only is
maintaining the allowed IPs going to be extra work, I'd assume your
desktops use DHCP, which means the IPs could change!

Just doesn't make sense to me to limit the connections to whitelisted
IPs
when the app is designed for use by users at there desktop.

Instead, isn't there some way you could blacklist an IP temporarily? So
run
the penitration team does there thing, they'll get connection a few time
but
after so many invalid attemps, you'll stop accepting connections from
that
IP.

As a plus, your app will still be protected if the penetration team
happens
to be working from a PC that you were going to whitelist originally; or
if
in the real world that users PC is actually compromised.

Just a thought.

Charles

On Thu, Jun 25, 2009 at 3:29 PM, Blalock, Bill
<Bill.Blalock@xxxxxxxx>wrote:

Thanks for your interest Charles and Peter.

Charles is right, I was wrong about

- allow it to listen only on port 3111

Isn't anything I need to be concerned with. "MY" program will listen

to

only the ports I tell it to. Restricting "MY" program to listen to

only

that port won't do anything to stop the "penetration tests" because it
isn't listening to any ports I haven't already told it to.

The problem is that I assumed when writing the program "anyone"
connecting on port 3111 is valid and tried to connect. I assumed it

was

safe since the i5 is on a private network behind multiple firewalls --
silly me! The penetration tests come along, find something is

listening

on the i5 at that port and pound on it.

Drew

but isn't it possible to have a timeout when listening on a port,
like you can with a data queue? Then the program could listen to
1 port for say 500ms, and if nothing arrived, listen on the other
port for 500ms, etc.

It is easier write the class which listens to the port to extend

Thread

or implement Runnable and start it in its own thread as Charles
suggests. That way the rest of the application keeps on doing its

thing

while the instance of the class(es) wait for something to arrive on

the

port.

The challenge is to ignore that attempts to connect to the port that
isn't a list of client computers.

- This could be done by the class which listens to the thread.
- It can be done by implementing SecurityManager and granting

"connect"

permission to the client computers.
- Someone else has suggested I look at JTOpen Permissions class

(haven't

done that but intend to.

I seem to have gotten around the problem I requested help for, not

quite

sure which which fixed it. I'll post the solution, which I am still
testing, in case it helps anyone else

1. Add these two properties to RUNJVA PROP parameter
(java.security.manager)
(java.security.policy 'sysmon.policy')
2. sysmon.policy has these entries:
// general permissions
grant {
permission java.util.PropertyPermission "*", "read,write";
permission java.lang.reflect.ReflectPermission

"suppressAccessChecks";

permission java.lang.RuntimePermission "*";
permission javax.net.ssl.SSLPermission "getSSLSessionContext";
permission java.io.FilePermission
"/QIBM/ProdData/Java400/jdk15/lib/-", "read";

// Socket permissions to let Java work
permission java.net.SocketPermission "localhost:0-1023",
"listen,accept,connect,resolve";
permission java.net.SocketPermission "localhost:8473",
"listen,accept,connect,resolve";

//permissions to files used in the application
permission java.io.FilePermission "/java/sysmon_test/-",
"read,write,delete";
permission java.io.FilePermission "/127.0.0.1/ftp/-", "read,

execute";

// The IFSFILE access errors stops once the above were in the policy
file

// permission to each client computer
permission java.net.SocketPermission "Client computer domain:1024-",
"accept,resolve";

};


-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Peter Dow
Sent: Thursday, June 25, 2009 12:33 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Need help with SecurityManager and errors thrown by JT400
classIFSFile

Hi Charles,

I'm kind of ignorant in this area, but isn't it possible to have a
timeout when listening on a port, like you can with a data queue?

Then

the program could listen to 1 port for say 500ms, and if nothing
arrived, listen on the other port for 500ms, etc.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Charles Wilt wrote:

On Wed, Jun 24, 2009 at 5:34 PM, Blalock, Bill

<Bill.Blalock@xxxxxxxx>wrote:

My thought was to use security manager to

- allow it to listen only on port 3111

- allow it only to accept connections from a list of desktop
client names in the policy file

Bill,

Not familiar with Security manager, but thought I'd point out that

an

applications (thread) can only listen on specific one port

regardless.

If you wanted an application to listen on two ports, for instance

one

unsecured and one secured like http does, you'd have to have two

separate

threads running; each listening to a specific port.

Charles

--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.

_____________

The information contained in this message is proprietary and/or
confidential. If you are not the
intended recipient, please: (i) delete the message and all copies;

(ii) do

not disclose,
distribute or use the message in any manner; and (iii) notify the

sender

immediately. In addition,
please be aware that any message addressed to our domain is subject to
archiving and review by
persons other than the intended recipient. Thank you.
_____________
--
This is the Java Programming on and around the iSeries / AS400

(JAVA400-L)

mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.