The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/hacking/unix/trsxenix.txt

Text File | 2003-06-11 | 14.6 KB | 324 lines

(c) April 15, 1987

Security Issues Involving Tandy Xenix Systems

Ward D. Griffiths III

Competitive Concepts, Inc.
1100 South Euclid Street
La Habra, CA  90631
[phone]

This paper provides advice and warnings
concerning security on Tandy Xenix systems
for system operators in the small business environment.
Specific attention is given to situations
unique to Tandy Xenix and applications
and to information not explicitly provided
in the Tandy manuals.

Introduction

In a data processing environment,
security is an important factor to reckon with.
When most timesharing systems were supervised
by folks with extensive training in data processing,
those systems could be monitored by people knowledgeable in security issues,
and could be kept safe.
When microcomputers first appeared,
security was generally a matter of locking up a box of diskettes.
With the power that once required expensive minicomputers now sitting on
desktops, being run by managers with little or no formal training,
simply desiring to run their businesses effectively,
any security loopholes can be critical.
A small business whose database or bookkeeping files
are destroyed or compromised by a stranger or disgruntled employee
may not be able to survive.
As the most common small multi-user system in the hands of such users
is the Tandy/Radio Shack Model 16 or Tandy 6000 running Xenix System III,
this article discusses that system specifically,
although most of the factors should apply to Xenix V/286
and to many other small Unix systems.

While the 'core' or 'runtime' version of Xenix
provided by Tandy with the Tandy 6000 contains everything required
to use their 'off-the-shelf' application software,
I strongly recommend acquiring the Development System.
Though the bulk of its material is not immediately useful to a business user,
it provides a number of utility programs
helpful in securing and monitoring the system,
such as process and login accounting, password administration,
and electronic mail, which will be mentioned later in this article.
The $750 list is a small price to pay for the security that it can provide,
and the five volumes of reference manuals,
while intimidating at first, will be invaluable later on.
Possesion of a 'Development System' does not mean that you have to develop
your own programs.

Account Maintenance

Before doing anything else, make sure that only those users who really
need access to your system have login accounts.
If anyone with an account has quit or been terminated,
get that user out of the system! or little other advice will do any good.
If you have set up accounts for people who may need them later,
but are not yet using the system, remove those as well,
especially if you use any predictable way of assigning initial passwords,
such as the same for everyone or each person's last name.
A user whose password can be guessed is always a security risk.
The ability to sign on to the system or not
is your first and most important line of defense,
and if you have compromised or unpassworded accounts,
they are a detour through Belgium around any Maginot line you can build.

Profile-16 & filePro

Probably the single largest security weakness
in stock Tandy 6000 Xenix systems
is the result of installing the Profile-16 database system (or filePro-16),
produced by the Small Computer Company and sold by Tandy as well as Small.
The installation process creates an entry in the password file
for a user named \fBprofile\fR,
who owns and operates the program and database files.
Most of the executable files in the database use the setuid mode
(fooling the system into thinking that one user is another)
to grant regular users access to the databases.
When the user \fBprofile\fR is created,
the account has no password, and many managers are unaware that the entry
is made, allowing any casual passer-by with a little bit of savvy
to gain easy access to their systems. In fact, one of the database creation
programs performs a \fBsetuid\fR to \fBroot\fR,
and if invoked with the "right" options can allow any person on the
unrestricted Bourne or C shell to gain superuser privilege
without any need to use the root password.
While I do not feel free to give exact instructions here,
the method is common knowledge in Tandy's Training and Support network.
Protection from it, however, is easy:
(assuming the programs are installed on the primary drive), a simple

chmod go-rwx /appl/pf/lib

will leave the programs usable from within the database system,
but inaccessible from the shell. Meanwhile, \fBpasswd\fR or cripple the
user named \fBprofile\fR. While the entry is required by the program,
it does not need and should not have actual \fBlogin\fR privilege.

Other Ghost Accounts

Another mystery user common to most systems is \fBuucpmgr\fR.
If \fBuucp\fR is not being used,
as it is not used on at least 90% of the Tandy Xenix systems in the field,
cripple that account as well.
Even if \fBuucp\fR is on-line,
its manager rarely needs to sign on,
since \fBroot\fR can do anything needed.
Some of the files and programs require the user and group numbers
assigned to \fBuucpmgr\fR,
but access to the shell is an unnecessary risk.

If you have any doubts about the security of your system, the first thing to
do is \fBcat /etc/passwd\fR and look for empty password fields.
Any user entry with a pair of colons (\fB::\fR) after the name
should be removed or passworded. The only exception I allow
is the user \fBwho\fR.

The Restricted Shell

When the \fBmkuser\fR program is executed,
you are given three choices as to which shell (command interpreter)
each user is going to run at \fBlogin\fR: \fBsh\fR, the standard Bourne shell,
\fBcsh\fR, the Berkley C shell, or \fBvsh\fR, the Microsoft Visual shell
with a user interface similar to Multiplan or Microsoft Word.
All three of these shells, as well as Tandy's \fBtsh\fR TRSDOS-style shell,
grant users abilities that you may not want them to have.
If you know how to use an editor, you can manually edit the
\fB/etc/passwd\fR file to give you a fourth and much safer choice.
There is a version of the standard (Bourne) shell, \fBrsh\fR,
with abilities greatly reduced from the its usual form.
Among other restrictions, the \fBcd\fR command is prohibited,
and the user is not allowed to set his own command search path
(or start a command with a slash to specify the full pathname).
Keep those users who are only running applications on that restricted shell,
or set them up on front-end menus that don't encourage system access.
A simple \fB'exec menu'\fR at the tail end of \fB.profile\fR can work wonders.
Profile and filePro provide a convenient menu generator
which is nicely documented, and is a lot easier for a part-time root
to use than writing shell scripts, although the menus when running do eat
a fair chunk of RAM and swap space. I do not recommend nesting them
(calling one menu from another).

User Command Paths

Leave \fB/bin/sh\fR, \fB/usr/bin/vsh\fR, \fB/bin/csh\fR and \fB/bin/tsh\fR
out of the search path given to your restricted users,
as all four shells immediately unrestrict at execution.
The method that I use is to create separate directories for those users
(\fB/rbin\fR, \fB/usr/rbin\fR), and link into those directories those files
I feel safe for them to use
(\fBlc\fR, \fBcat\fR, \fBmore\fR, \fBcp\fR, and various application startups),
leaving \fB/bin\fR and \fB/usr/bin\fR completely out of their view.
As a side affect, users should not own their \fB.profile\fR scripts:
otherwise, they can edit them back to whichever search path they desire.
I have set up a master \fB.profile\fR in \fB/usr/lib/mkuser/mkuser.prof\fR,
and each time a user is created,
it is linked instead of copied into the new home directory.
This allows me to make global changes affecting all regular users,
instead of editing them one at a time.

Password Administration

If it is available,
don't hesitate to inflict password administration on your people.
If people are forced to change their passwords periodically,
it not only enforces a bit of added security,
it keeps their memories sharp.
The \fBpwadmin\fR command is part of the Development System,
and lets you specify how often a user is required to change his password,
as well as how long before he can change it again, keeping him from going
right back to his previous and probably compromised password.

Login & Process Accounting

Again if available,
use login and process accounting,
and scan the files periodically.
My preferred way to do that is to use a \fBcrontab\fR
entry to \fBmail\fR the results to \fBroot\fR
or his designated representative every night.
My designated representative is named monitor,
and the only thing he is allowed to do is to read his mail.
He should read his mail fairly often,
as the files can take up a considerable amount of room on the disk(s).

Access Permission Settings

Speaking of mail, change the mode on user mailboxes to read/write for the
owner only. The default allows any user to read any other user's mail,
not usually a serious security problem for the system,
but it limits how much the users will use electronic instead of paper messages
to communicate with each other.
Any computer installation is a paper factory,
but why make it any worse than it already is?

While you are changing permissions,
another good place to allow privacy
is the home directories of individual users.
Except in rare cases,
no user generally needs direct access
to another user's directory or the contents thereof.
Those occasional documents and spreadsheets needing to be shared
can be linked to each directory,
or placed in a directory common to a group,
though the second choice doesn't work for users on the restricted shell.

There are a number of files in the directories \fB/etc\fR and \fB/usr/adm\fR
which should be protected from casual reading or execution,
especially if process accounting is in effect.
These include \fB/etc/logbook\fR,
\fB/etc/rc\fR and any supplemental \fBrc.*\fR files, and
 any
files in \fB/usr/adm\fR involving accounting or user monitoring
(\fBpacct\fR, \fBwtmp\fR, etc.).

Modem Lines

Keep an eye on any dial-in modem lines.
At the same time process information is sent to "monitor",
I have a duplicate set of those processes performed on my single modem
appended to a file all its own.
As yet, I haven't seen anything odd,
as the telephone number is known only to those people who need to use it,
but a little healthy paranoia in advance of need
is better than ugly recriminations afterward.
Besides telling you who logged in and when,
lines without user names will tell you
when the modem answered the phone without a successful \fBlogin\fR.
When in doubt,there are modems on the market which keep a list of authorized
users and call each user back at a number programmed into the modem itself
along with a name and password independent of the name or password
on the actual system. These modems are getting less expensive all the time,
and at this writing have just dropped below $500 retail at 1200 baud.

Physical Security

Contrary to the information given in the Tandy user's guide, it is not
necessary to reinstall Xenix simply because you forget the root password.
It is possible to reset the console, boot from a floppy,
then clean and mount the primary hard disk as a subordinate file system.
This completely goes around the password file on the hard disk,
and it is possible for anyone with physical access to the console to do it.
Once into the file system in single-user mode,
the root password can be removed, or a backdoor can be installed.
When the console is unattended, lock the door.
Pretend that it is the box of money which it effectively is.
The same applies to backup media, whether diskettes, tapes or Bernoulli
cartridges.
If someone with access to a similar system has access to your backups,
that person can restore your data to the other system and read your secrets
at his leisure.
While the \bcrypt\r command in the development system will let you encode
personal files so that they can only be read by someone with the correct key,
most (all Tandy) application programs choke on encrypted files. Keep your
backups under lock and key, preferably at another location, any time you're
not actually backing up or restoring your data.

Tracking System Changes

The Tandy user's guide recommends
that you do not modify the file \fB/etc/logbook\fR,
so that their customer support folks
can determine software versions and installation dates.
I suggest adding to that file a mention of any changes made
to system or application programs,
files or directories,
including permission changes such
as that mentioned above to \fB/appl/pf/lib\fR.
As long as you don't change the lines provided
by the various software installation scripts,
the folks at Tandy aren't likely to mind.
It can actually help with troubleshooting on some occasions,
as in the case where that \fBchmod\fR is done incorrectly,
and Profile-16 refuses to operate properly as is likely to happen.

Before making any real changes to your system,
make a hard copy of its condition before the operation,
so that if necessary,
it can at least be returned to stock condition.

For example:

.ft B
.br
# l /appl/pf | pr | lpr
.br
# chmod go-rwx /appl/pf/lib
.br
# l /appl/pf | pr | lpr
.br
.ft R

If afterward any function of Profile-16 doesn't work, the first printout can
be used to change it back for another attempt.

Conclusion

No single article can cover all aspects of security on any one system, let
alone an entire series of systems with each machine configured differently.
Each application program installed can cause potential problems, Microsoft
may have left back doors created by its own people (or not found and removed
some created previously during the evolution of Unix), and I suspect that
I might have missed a few on my system, though I keep experimenting from
the point of view of someone wanting to lay waste to my data.
I have plugged all of the gaps that I have found so far, but locks keep out
honest people, and there may be an 11-year-old out there who has already
found a way around everything I've done. I just keep a sharp eye out for
anything suspicious. The power of the Xenix operating system is too valuable
to abandon just because the very nature of its multi-user abilities implies
a small factor of risk. The risks can be minimized. In terms of protecting
data and files from prying eyes, administrators of MS-DOS networks using
networks of IBM PC's and clones are the ones who really have their work cut
out for them.
==============================================================================