Hi Scott,
I'm surprised you feel securing what can be executed on a system as silly. Not doing so, from my knothole onto the world, seems absurd. To me, it is akin to buying a padlock for a locker but not actually locking it!!
If you can't get from system A to System B because the stuff allowing it is unavailable to you who cares how tightly system B is locked down? System A isn't letting you get there anyway.
A worm goes here
A worm goes there
Until it is stopped from going anywhere.
It is stopped when it cannot execute stuff allowing it go somewhere.
Gary Monnier
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, May 17, 2012 2:03 PM
To: Midrange Systems Technical Discussion
Subject: Re: RMTCMD's security?
Hi Gary,
I was responding to Rob's message, where he referred to the client system as the "from" system, and the server system as the "to" system.
I don't know what "host" and "target" mean in your message. To me, they are even more ambiguous as "from" and "to". All systems can be referred to as hosts.
This thread originated with a poster saying he wanted to secure his system by locking down the "SBMRMTCMD" command. In other words, he's protecting the server system by restricting access to the client-side command.
The problem with that is that it only restricts one command on one computer. Anyone can either write, buy, or download a free tool to submit the same command without using the IBM-supplied SBMRMTCMD.
Likewise, they can submit the command from another computer. In all cases, bypassing the security placed on the SBMRMTCMD parameter.
I suppose in a very small, tightly controlled, environment, it might be possible to control every computer that can submit a command, and every program on that computer. But in that case, there's a lot more going on than simple securing access to SBMRMTCMD, there's also the network security and physical security that prevents attackers from bringing in their own computer, or connecting from outside. Even with that level of physical and network security, it's easy for someone down the road to forget to enforce some aspect of it, and bring in a smartphone or computer that hasn't been secured. Or allow someone to write/install a program that could run a remote command. It's not a good way to run security!!
The proper way to secure remote commands is on the server-side. The TCP/IP service that receives the remote command could have exit programs to restrict which commands can be run. Or a userid/password (or with newer tools, a digital key or certificate) can be used to enforce the operating system's object-level security. Once this security is enforced on the server-side, it doesn't matter how the client-side program is secured, or which program they run, or which computer the request comes from, because the server will only run the commands that are allowed.
The fact that people on this list (besides Chuck and Rob) seem to be advocating securing the SBMRMTCMD or RUNRMTCMD command is just silly.
On 5/17/2012 2:12 PM, Monnier, Gary wrote:
Scott,
By "to" machine do you mean the target system or the host system?
Gary Monnier
midrange.com
