Learning a New OS... and Fast!?

Inexile2002 asks: "I've been asked to assist a consultant on a project using VMS and basically have four days to figure out enough that I'm actually of some use. (We're not doing development, just security reviews, so I'm not totally screwed.) Originally I was going to ask for advice on how to start teaching myself VMS from scratch including best books and support websites when I realized that there is a more generic issue here. What are people's thoughts on learning a new OS and learning it fast? Have people found optimal ways to pick things up quickly, get a familiarity with commands and underlying logic? How about learning the basics when you can't actually install and play with the OS in question?"

Comments

Focus on the code.

[mcgroarty]

If you're being brought in to do security audits, the only honest thing for you to do is to focus on looking at code and have someone else look at the bigger picture stuff.

You can not learn enough about an OS to consult on its security, and if I'd hired you to look at my systems and later found out you hadn't even been on them a week prior, I'd likely turn around and sue you pantless.

If strictly looking at code or similar is your plan, and you're only worried about being able to navigate the system enough to look at source, I'd suggest looking at the little intros that are part of any college coursework involving the OS. Chance are you can find all kinds of class notes and course workbooks with Google.

Actually...

[Inexile2002]

I'm not going to actually touch a machine. Period. I'm going to be handling physical security and the people side of the policy - ie. What business process are involved in granting or revoking user accounts and how are code changes managed on a process side. That's my job.

I do touch the tech often enough that I'm helping out the VMS guy. Mostly, that'll mean doing his documentation for him when he's done his testing. I just want to be conversant enough that I won't be a time suck while I document everything. As for learning, I find I don't know what to ask the sys admins if I don't know anything about the OS. Even when I know the system, I play dumb... it's just going to be much much easier to play dumb for VMS.

Basically, I could go in to this and not know a thing about VMS and it wouldn't really hurt my ability to do my job. However, that's not the way I like to do things... I handle processes and policies but the more I know about the client...

Some information on VMS

[TSTM]

A very good collection of links and information conserning VMS can be found here

The site is very insightful.. and I think it can be read through in a couple of hours. =)

VMS is easy

[NTT]

It seems you asked 2 questions. The first being (seemingly): help me learn VMS in 4 days. The other being about the general opinion of learning a new OS. I figured I throw my hat in to the ring on the first one. (I use OpenVMS at work, and Linux at home; I figure I'm qualified).

VMS is really quite similar to Unix-y OS's. What really flipped the switch for me was the how to pass parameters to the commands in VMS.

This page has helped me the most. In fact I have a print out taped up in my cube for easy reference.
http://www.physnet.uni-hamburg.de/phys net/vms-unix -commands.html
Dont get discouraged by some of the long commands. As long as you have the unique chars it knows what you mean. The command DIRECTORY is shortened to DIR.
Also the man equivelent in VMS is the HELP command. The help docs are complete and very well done.

The other trick to learning VMS fast is to know the directory syntax. Instead of #cd /path/to/this/file.txt it is $set def(ault) [path.to.this]file.txt. Directories are surrounded by [square brackets] with dots "." separating sub-dirs. Also there are probably multiple file systems on several disks; the disk where the OS lives is most likely called DISK$SYSTEM, and the users (aka /home) is prolly on DISK$LOG. You can bounce around from folder to folder without specifying the filesystem, but to move to another fs you have to specify it: SET DEF DISK$SYSTEM:[PATH.TO.THIS]FILE.TXT

On a side note, stay away from the VMS to Linux HOWTO. It has *very* little helpful info, except for the first few pages that show the related Linux commands.

backwards

[Inominate]

We're not doing development, just security reviews, so I'm not totally screwed.)

You've got this backwards. Security requires more indepth knowledge of the OS than development. If they've got you doing security reviews for a system you don't know how to use, I'm sure there are a few hundred script kiddies around who'd love to know who you're doing this for.

Links

[jbolden]

Well I'm reading the links below and one that didn't get mentioned kind of suprised me Open VMS documentation.

Anyway VMS security is nothing like Unix security. Oracle or NT security is much closer to the security model. VMS admins don't tend to modify the base systems very much and VMS is very secure by default. So I wouldn't be looking for Linuxy holes like the equivelent of "sendmail" exploits. The real problem you'll have is finding out which users can elevate privledge, and privledges that in combination can give them a great deal of authority.

In my experience the hole that VMS guys tend to miss is this: Unaudited program gives the author the authority of the user running the program. So if Joe submits changes to the "update accounts file" and update accounts runs as a system operator on the production box then Joe has system operator permissions unless someone is checking his code carefully. Unix guys tend to see this as obvious VMS guys tend to miss this since Joe may not officially even have a log in ont he production box.

And the old VMS farts will tell you...

[devphil]

...that on any decent VMS system,

HELP topic

will start a surprisingly friendly hierarchical help menu on "topic". Or don't specify a topic and just wander around the help tree.

Just as "man man" is a useful command to give to Unix newbies, "HELP HELP" is a good starting point for VMS. My first networked machine was a VMS. When I finally moved to Unix, I was so diappointed in the man pages. "You have to type the whole name of the topic? It can't figure it out? Sheesh..."

Like the tagline goes: VMS is a text-based adventure game. If you win, you get to use Unix.

Re:And the old VMS farts will tell you...

[iankerickson]

Use the HELP command?

I disagree completely. The HELP command on VMS has good docs written in fairly plain english, and it is easier to browse than man. But a lot of VMS info isn't in the help/message system.

I'd focus on the manuals first, since they actually explain the concepts. HELP is mostly just a quick reference. VMS comes with a CD of manuals in HTML and PDF, and there's a web site as well with those. If you read off a screen faster than off paper, then there you go. I think SYS$HELP: also has txt copies of some docs, if they were installed.

You can also get a VAX emulator to experiment with. CHARON used to have a free version. The project that wrote the free PDP-11 emulator has a free VAX emulator too. You'll need the install sets from the tape or CD and a valid liscence PAK for VMS. If you "borrow" the PAK from a real VAX on your LAN, you may want to avoid experimenting with networking (besides being "illegal" -- gasp!).

As far as learning an OS quickly?
- 4 days isn't enough time. I say 7 to 30.

- Learn the shell and make a quick reference sheet of the sytax/commands.

- Learn the editor and do the same thing.

- Then learn how to customize the editor and do automation. EVE on VMS is underrated. You can write your own commands and maps them to keys, edit multiple files, run DCL from EVE and stick the output in a file, edit ASCII tables in block mode. And you can remap the keys. I have an EVE$INIT.EVE that leave all the standard/default keys alone, but maps all the standard commands like GET FILE to things like GOLD-O, etc. There's also EDT, but I'd learn just enough of it to be able to get out of it.

- Learn how to write scripts. On VMS you have @ and .COM files, and EVE is written in TPU which has text-oriented features. If you learned the shell syntax and the editor, then you're all set. Then you can edit startup scripts like LOGIN.COM and EVE$INIT.TPU to have all the settings you want to have all the time.

- Learn how to multitask from the shell. On VMS, the commands you want are SPAWN and ATTACH. The trick is to SPAWN the program with a process name that you pick, the use attach to switch to it. From DCL, you can use DEFINE to map the ATTACH command to a function key. From programs like EVE you again map the ATTACH command to a key to switch back to DCL. Once you get the idea, you can do one-touch task switching between DCL, EVE, pine, lynx, NOTES, and you're own programs. Then VMS doesn't seem like such a typing contest to use.

- Learn the boot process of the hardware and OS completely. FE, on VMS the boot scripts set most of the logicals and symbols. People who don't understand this tend to think they can set symbols ad hoc, then reboot the VAX if there's a problem, and the symbol will still be there. Nuh uh. Sorry.

- Also learn how to "break in" by booting up by an alternate means. If you get locked out of a machine by a coworker or assume duties of a neglected box, it nice to know which manual the procedure is in than having to wonder if you can get in at all.

- Then learn how to find, download, and install freeware from off the net. No matter how obscure a computer may be, someone has written software for it, and someone else has a collection of it on the internet for you to download. You can learn a lot by trying to install new software on an OS. You can also fuck up your production system, so use an unpriviledged account on the test systemaa (after updating your backups first) and be careful. VMS was once the MS Windows of mainframes, and it did have viruses, trojans, and other malware.

- Try installing the OS from scratch, if you can. This is where an emulator rules. It dispenses with the need for a "spare" VAX to ruin, and emulators have feature that allow you to cheat. Often you can pause the CPU and scan memory for strings, or save and restore snapshots of the disk or the entire state of the emulated machine. Then you can try all kinds of reckless and stupid things without hosing the OS (just restore a snapshot). If you wanted to learn NT from scratch, having Bochs, VMWare, or VirtualPC would give you the same advantage.

- Last, learn how to use the built-in commands to write, compile, and run your own binaries. VMS usually doesn't come with compilers unless you buy them (I think) but MACRO assembly is standard. Most wouldn't go that far, but if you really want to learn an OS, learning how to write applications for it opens all the doors. Unfortunately, you really should know all the previous stuff first or you get stuck on simple things. Assembly may sound extreme, but it's absurd how much information you can get from a binary by running it through a decompiler. If you know enough asm to be able to look up what you need to know, then that's enough to get by.

I once had a VMS problem where a W32 client would crash when the user used a "Print Preview" function. A lot of spring cleaning had been done on the VAX to remove what the vendor told us were old, useless files that were safe to delete. Ha ha ha. Fortunately I had installed infozip a while back and zip'd up these "junk" files before deleting them. But there were no log or error messages that told us what was wrong with the client (it just Dr. Watson'd). I used cygwin to run 'strings' on the client exe, and listed in there was a pathname to one of the files we'd deleted. For fun I made an empty file with CREATE on the VAX with the same name, and like that the problem was gone. The client only tested for the existance of that file, but didn't actually need its contents.

I've used the same basic steps to learn several platforms: Macs, Solaris, NT, DOS, Linux, etc. People get superstitious around computers. even experienced people. It'd be no different on other wierd architectures, like an AS/400 or a old 8-bit PC from the 80s. It's mostly just process of elimination.

Re:VMS!=COBOL?

[NTT]

You just have to get enough chars to make it unique from any other command. Just like tab-completion. DIFF is not DIR, but DI(FF) will get confused with DI(R).

For Clarity's Sake

[Inexile2002]

First off... I will not be touching machines.

Second, by security reviews... I should have been clearer... not securing the boxes on any kind of code or OS level... if the sys admin isn't doing his job I'll never damn well know. I'll be reviewing security policy. Who has authority to sign off on new user accounts? Has this person signed off on new user accounts? What is the process for notifying the sys admin to remove an account? Has everyone who's departed the company had their account deleted? This is the kind of security review I'm responsible for. I also look at who has the ability to actually walk up to the box. I assess adequacy of the security physically getting into the server room.

I'm not totally stupid. If they wanted me to actually touch a keyboard on a machine who's OS I didn't know - I would tell them to find someone else. (Hell, because of the nature of what I do, I'm reluctant to touch the machines I do know.) I try to learn as much as I can before I go in because that is the way I prefer to work.

There are people in my shop who wouldn't know a shell script from a hollywood script and they can do the same job I do and do it competently. I just like to know as much as I can about the system.

And so far the best suggestions have been to read the online stuff and not sleep... already doing that. (Avoiding /. is a good suggestion too frankly, but at 3AM I need a break.)

Free account on a VMS machine

[jpkunst]

is available here:

http://www.thevax.org/.

It's a free service run by hobbyists.

HTH,
JP

Seek good documentation first.

[Doctor Hu]

This applies to all OSes, of course. And find someone familiar with the OS to tell you what's important to read first (particularly important with systems where the documentation extends to several meters of bookshelf in printed form). It's some time since I worked with VMS, but here are a few pointers:

VMS Documentation:

http://www.openvms.compaq.com/doc/

VMS OS Documentation:

http://www.openvms.compaq.com/doc/os731_index.html

Look in particular at "OpenVMS User's Manual" for starters, then "OpenVMS System Manager's Manual", and "OpenVMS Guide to System Security".

VMS security is fairly fine-grained and the OS is pretty secure by default provided people (and processes, eg backups) are granted privileges on the basis of the minimum needed to perform their work, and passwords for the really dangerous accounts are kept under tight control (place I used to work had the password for the all-powerful "system" account in a sealed envelope in a safe). Oh, and if you have physical access to the system console then there are alternative boot modes which can override all the OS protections. They're well-documented.

System Management:

http://www.openvms.compaq.com/openvms/system_manag ement.html - though at first glance this looks to be more a "here are some fine extra products you can buy to help you" page than detailed technical information.

More VMS Documentation:

http://www.openvms.compaq.com/wizard/openvms_faq.h tml

Yet more VMS Documentation:

Type "HELP" at the command line.

Notwithstanding your clarifications of what you'll be doing, good luck.

From an old fart who has used VMS over 20 years

[hughk]

The main point of VMS is that you can do a lot with it. However, VMS security revolves around unique users, who have identifiers that give them access rights and sometimes privileges. Applications sometimes do their own thing, this has an unpleasant effect of bypassing the user model.

The main point is ensuring that accounts can be tied to users (as that is what gets audited) and that unlike Unix, you may have many system administrators with individual accounts. VMS also supports the concept of Security Administrators as separate from the System Administrator.

What you are looking for is documentation on who can do what and who approves it. For various reasons, it is a good idea to keep users or at least their rights identifiers around for a long time, even after users have left. It is better to disable the user until you are certain that their rights identifier is no longer in the system.

As with many systems, an OpenVMS console can be used for breaking into the system. However, it can be secured in such a way that bypassing security is extremely difficult.