(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version



Security: COPS



More Security Articles

More Articles

COPS

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:

Configuration

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:

SECURE=`pwd`
 

You'll also want to change the line a few lines up (86 in mine) so that it says:

BIT_BUCKET=`pwd`/cops.errors
 

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.


© December 1998 by Anthony Lawrence. All rights reserved.




Click here to add your comments



Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar




Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.


book graphic unix and linux troubleshooting guide

My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!



 I sell and support
 Kerio Mail server




pavatar.jpg
More:
       - Security


Unix/Linux Consultants

Skills Tests

Guest Post Here











My Favorites

Change Congress