Re: RMTCMD's security?

On 17 May 2012 12:41, Monnier, Gary wrote:

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.

No such implication. In fact I _asked_ in what ways the implied resolution [by providing "alternative options" to the commands] would be a resolution, and for whom. Were they suggesting merely to appease the auditors, even though possibly, effectively nothing has changed? Other tooling and programming can give the same function of the since locked-down commands; even those same commands may exist on other systems in the network. Unless the target system blocks such requests, attempts to block such requests from every possible source\client could be somewhat futile; with regard to the effect on the security of the target.

In my stated opinion, I was alluding something analogous to... The owners of a self-service storage facility previously had given to some people, some keys to its various lockers. Those people should no longer have access to those lockers. The owners have blockaded all but a few entrances to the areas where the lockers are located within the storage facility. However the locks on the lockers in the facility remain unchanged. Is the storage facility effectively as insecure as it was prior to the blockades being installed? Nothing alluded in the scenario prevents those holding the keys from using one of the entrances that is not blockaded, thus they are able to access the lockers with the keys they were given previously.

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 )?

Effectively. And even if some feature is employed to deny the authenticated user any access to certain unsecured resources via each of those specific methods\interfaces to access the system, then still lacking resource security at the target, there remains any possible alternate means of access not yet realized by the system owner; i.e. via means for which preventive measures have not yet been employed. That is, the users still have the keys, but there could remain some entrances that have not been blockaded; if they should not have the access [the keys], then the resources must be protected with exclusionary authority [new locks].

Or two questions... :)

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?

Inherently; as much as passwords can be trusted. But authentication is only part of the process; that is merely the entry-point. What matters then, is the access to the resources. That is true whether access to the resources is via a proxy or the authenticated user; e.g. authentication may be from somewhere else in the network, thus entry could be granted, so effectively the authorities to the resources are all that remain to protect those resources.

If that authenticated user has more access\authorization than is required to do their work at the target, then they can still do accidental or nefarious harm. Via usr\pwd they can gain entry, and by authority to the resources they have the keys. So even when access methods A and B may prevent the authenticated user from performing something they should not, there still remains the possibility of access methods Y and Z for which similar preventives have not been employed; e.g. menu-based security is of no assistance, when the access is not ensured to be limited only to menus.

If that authenticated user has no access\authorization beyond what is required to do their work at the target, then they can only do what they are authorized to do.

Regards, Chuck