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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at

This thread ...


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

This mailing list archive is Copyright 1997-2019 by 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].