The COPS (Computer Oracle and Password System) is designed to be part of a security solution. It does not prevent attacks, break ins, or anything else, but it does check your system to help you identify and eliminate security holes and weaknesses. Think of it as an inspection rather than a guard.
You can get COPS from ftp://ftp.celestial.com/pub/sco-ports/ as source or in binary form. It comes as both a series of shell scripts that drive the compiled programs, or as a series of Perl programs.
Forget the Perl. It's old, it's buggy, and it just does not work well.
The shell based programs are in a little better shape, but they need a lot of work for OSR5, mostly because they expect things in different places than SCO OSR5 has them. You can get quite a bit of useful work out of COPS without changing anything, but you'll miss certain features. Unfortunately, you might not even notice that you missed anything: by default, all error output is thrown to /dev/null! If you don't change that, you won't see the errors, and (as supplied, and run on SCO OSR5), the errors are numerous. But even more unfortunately, the stderr also contains a great deal of debugging type output, most of which is gibberish without going back and examining the sources, so it's not all that easy to separate real configuration issues from all that fluff.
The README files imply that upon receipt, you should execute the "reconfig" script, and check the "docs" directory for release specific readme files. The reconfig doesn't work completely, or at least doesn't work well: it misses the "bug.chk" file (one of the scripts that the main program drives), so that ends up looking for awk in the wrong place. As for the readme files in the docs directory, there's nothing related to SCO except for some notes in a readme.shadow file; and even that is not particularly well explained: the idea seems to be that you will use this to produce a substitute password file, which would make you think (wrongly) that the password checking tests aren't going to work as supplied. Wrong, they do work, so you don't need the readme.shadow suggestions at all.
You'd think I would have given up before now, but I felt that the concept is sound, and although the execution is badly flawed (at least in this environment), there is enough value here to proceed. So let's look at what you have to do at a bare minimum:
I guess you might as well start doing it their way. Therefore, the first thing to do is to run "./reconfig". You'll either want to add "bug.chk" to its list of programs to modify or edit bug.chk by hand after running it. Run "make" to compile the C stuff. You then need to edit "cops" (it's just a shell script), and change out the line that was line 93 in the stuff I got so that it says:
You'll also want to change the line a few lines up (86 in mine) so that it says:
Now you are ready to run it. Type ./cops, and wait. It will take a pretty fair amount of time to sift through everything, but eventually you will get a prompt back. You'll also get your "cops.errors" file, which you should look at, and a new directory named after your machine. On my system, that's "scobox", and within the appropriate directory on your machine, you'll find a file with today's date as its name, and that file contains the results of the COPS inspection.
No doubt you'll immediately notice that COPS is wrong about certain things, paranoid about others, and blissfully unaware of things you might think rather important. All true, which means that if you want this to be useful for your system, you are going to have to get your hands dirty modifying it so that it is more SCO aware.
But you'll also notice that it can do some good things even as is. For example, if you have any users with easily cracked or null passwords, COPS will show you. If you were foolish enough to have any world writable setuid programs, it would catch those. It doesn't like anything in /etc to be writable, so you probably got some warnings there.
You also probably got warnings from the bug.chk that had to be modified above. If you look at what it is attempting to do, you'll immediately see that its guesses are only as good as the CERT list it is checking against and as good as the "platform" program does at identifying your Unix. And, if you'll look more closely, you'll find that "platform" doesn't match anything that bug.chk has any files for, so all it does it spit out some very generic warnings (actually, the script has a line that would tell you if it has no platform specific file, but that line is commented out!). This is another place you'd need to dig in and do some work if you wanted this to do what it says it is trying to do.
Unfortunately, there are probably more problems, more
assumptions buried within the shell scripts and the code. I don't
have the energy or the time to go digging through every line, and
you probably don't either. Is COPS worth the trouble? I guess I'd
answer with a qualified yes. You'll get some value "out of the
box", and can really add quite a bit more with a little bit of
effort, but I personally don't feel it is worth the trouble to work
at it hard enough to really fix it for SCO OpenServer.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-13 Tony Lawrence
Whenever the literary German dives into a sentence, that is the last you are going to see of him till he emerges on the other side of his Atlantic with his verb in his mouth. (Mark Twain)