× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Rob,

Not how I interpreted it but, it is a catch 22 is it not? What you ask holds true for someone that can utilize the CLI API, HLAPPI API or embedded SQL. Any of them can be used to access remote systems.

So, at the core is "How do you secure a system? To what level do you restrict object accessibility? How do you restrict clients from accessing your system be it a PC, iPad, Unix, System I, Linux?"

Where do you draw the line?

Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 17, 2012 12:57 PM
To: Midrange Systems Technical Discussion
Subject: RE: RMTCMD's security?

I think what Chuck is saying is that if you secure the command RUNRMTCMD on your i so that only a select few can run it then how does that secure someone from running the APIs utilized by that command? Not where I was going but that's my interpretation.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 05/17/2012 03:41 PM
Subject: RE: RMTCMD's security?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Chuck,

I've had to read your response several times and I have to say I'm at a
loss. You seem to be implying the System I doesn't provide any security
features, especially ones auditors will accept.

So let me ask you a question...

If someone can log onto a system can they perform any task they are
authorized to regardless of how they sign on ( TELNET, FTP, AREXEC,
RUNRMTCMD, HLAPPI API )?

Or two... :)

If someone is forced to provide a user name and password to sign onto a
system is the system more secure than if they do not have to provide them?


Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, May 17, 2012 11:18 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RMTCMD's security?

On 17 May 2012 09:37, Matt Olson wrote:
Using any of these commands is a PCI security auditors worst
nightmare. You might want to consider alternative options to using
these commands, we had to turn them all off after a security audit.

So is using an alternative to those commands, apparently private
features that would do effectively the same thing, somehow better for any
of the auditors, programmers, users, the security\integrity of the
requesting system, the security\integrity of the target system? If so,
then in what ways? Seems to me that if the target system was insecure
prior to the access to those features being denied, then the same
exposures remain at the target; being denied those methods still leaves
any other possible exploits... presumably even including the private
replacements.

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.