1748003 Members
4653 Online
108757 Solutions
New Discussion юеВ

Re: Recall Command

 
Robert_Boyd
Respected Contributor

Re: Recall Command

Hein,

Can you say some more about this idea of batch jobs (or is it reallly command procedures?) "scraping" the DCL buffer ?

I have wanted from the day that RECALL/OUTPUT came out to be able to have a logout command that would capture my command stream and let me reload it when I log back in.

The closest I ever came to this was setting up keypad commands to implement the RECALL/OUTPUT command. The problem with that is that it's just too much effort to remember to do it every time consistently, and it doesn't help when I'm logged in from a session where I don't have the luxury of a DEC compatible keypad/emulation readily accessible.

I'm curious about this malicious code idea -- if someone's already compromised the system enough to be able to put something like that into play, you're probably in deep trouble.

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
John Gillings
Honored Contributor

Re: Recall Command

>Can you say some more about this idea
>of batch jobs (or is it reallly command
>procedures?) "scraping" the DCL buffer ?

It's command procedures...

File name syntax includes the optional "access control string" for network file specifications:

node"username password"::dev:[dir]file.typ

So, suppose I type the command:

$ TYPE REM"SYSTEM SECRET"::DKA0:[HOME]MYFILE.DAT

to display a file on node REM, then sometime later I execute YOUR (trojan) command procedure "HANDY.COM"

Now, your procedure could RECALL/OUT *MY* recall buffer, parse the contents, and discover the triplet of node name, username and password.

For this and a few other reasons, the RECALL command is ignored from any command procedure. Think about it, what would a non-interactive RECALL command mean? Also, RECALL/IN could be used to plant trojan commands in the recall buffer of an unsuspecting user.

From a suitably privileged process, using SDA, the recall buffer can be determined for any process, from any version of OpenVMS, (VAX or Alpha), the CLUE PROCESS just makes it easier from V7.3-2.

Create a file:
$ CREATE RECALL.SDA
define prcbase = @(ctl$ag_clidata+ppd$q_clireg+4)
examine prcbase+prc_g_commands;400
examine prcbase+prc_l_recallptr

SDA:
SDA> READ SYS$SYSTEM:DCLDEF
SDA> @RECALL.SDA

(you'll have to work out where the commands start and stop yourself)
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Recall Command

Oops, forgot...

From Alpha it's

SDA> READ SYS$LOADABLE_IMAGES:DCLDEF

you will also have to increase the examine size from ";400"
A crucible of informative mistakes
Hein van den Heuvel
Honored Contributor

Re: Recall Command

Oops, don't know what made me write batch job. I meant command file as John suggested.
Supposedly you could be tricked into using a longish non-transparent command file which normally say gives you a build environment, but on special days or times peaks into you command buffer for usefull usename/passwords. Like Robert writes I believe that you have bigger problems than allowing recall/out in a command file if you had such trap on the box.
And like Robert I have wished to be able to do a simple build-in recovery of my last session, oh what a thousand times, and I have use a command line with embedded password maybe 5 times.
Anyway, for the actual problem Zeni tries to solve it does not seem enough to stick this in a command file to be executed say at logout. I'd sooner opt for random samples with SDA or a privved tool made for the purpose, or good old auditing.

I like Zeni observation that it needs not be perfect because he will be dealing with privved users anyway.

Hein.


Kris Clippeleyr
Honored Contributor

Re: Recall Command

Zeni,
In the days when comp.os.vms still contained real gems of freeware, I got my hands on the sources of the RETRIEVE program by Jo Torsmyr from Norway.
Before the extension of RECALL beyond the last 20 commands, I used this utility instead. It behaves similar to the RECALL command as we know it today, and has also the possibility of storing/retrieving the commands in/from a file.
The last time I used & tested it was on VAX/VMS V5.4, so no guarantees.
Btw, you'll need a Pascal compiler to build this thing.
Good luck,
Kris (aka Qkcl)
I'm gonna hit the highway like a battering ram on a silver-black phantom bike...
Ian Miller.
Honored Contributor

Re: Recall Command

I think that program will need some work due to DCL internal changes (EDCL project and more commands in the history).
____________________
Purely Personal Opinion
Ian Miller.
Honored Contributor

Re: Recall Command

The original requirement appears to obtain a record of what a privileged user did.

Parhaps using the LOGGER program or similar may be the best way forward.

What is the reason for the record?
____________________
Purely Personal Opinion
Zeni B. Schleter
Regular Advisor

Re: Recall Command

Good discussion. It will take me a bit to catch up with points but I will.
Reason for this effort is a security requirement. The constraint is that it has to be applicable to multiple platforms.
A by-product that will probably be more useful than the original intent will be that we can go back and review when we encounter such moments as "What did I do that caused that?" Usually encountered after reboots.
What is requested sounds a lot like the complete monitoring done by a VaxCluster console software for the OPA0 port. Time, Money, and effort is not on our side for that.
Robert_Boyd
Respected Contributor

Re: Recall Command

Zeni,

If you did have money and time and effort available there are some excellent products available such as ConsoleWorks, or Console Manager. I worked for about 9 years with Console Manager and I've also done some consulting on a pilot project for an installation of ConsoleWorks.

A procedural solution that is very inexpensive is something that I often do when such a product is not available. Especially for applying patches and some other major changes. I use the SET HOST/LOG capability (or TELNET) to log an entire session where I log in to the SYSTEM account to make major changes before a reboot. It does take some discipline to remember to do this, but it has helped in many cases to track down small but consequential errors.

Another tool I use is redirecting the output of the startup process very early in the startup by inserting a front end startup procedure that sets up the log file and passes control over to the normal startup.

I'm attaching my current version of that startup procedure here. I control the selection of it by inserting the following in SYS$SYSTEM:MODPARAMS.DAT:

STARTUP = "SYS$SYSTEM:ALT_STARTUP.COM"


It's also possible to use PIPE or other mechanisms to build a T connection so that the output can go to the console and to a log file at the same time, but I haven't experimented with that. I usually find that it's sufficient to capture it to a log file.

I realize that the startup parameters allow you to have the startup procedure log most of the output to a file. I prefer this mechanism to capture all of the output from the very beginning of the invocation of STARTUP. I also like being able to control the name of the log file so that multiple boots log to files with different names.

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Zeni B. Schleter
Regular Advisor

Re: Recall Command

We do use Set Host/Log when doing Installations . Very useful when doing repetive installs.
We use the Sysman method for startup and get the output in the standard startup.log. For shutdowns, we have started capturing that output in the method you described.