Section 2.5 Protecting the System from User Mistakes

   


2.5 Protecting the System from User Mistakes

graphics/fivedangerlevel.gif

There are many more users than SysAdmins, almost all are less knowledgeable about security, and most are too busy doing their job to worry about security. This is a really good reason to take steps to protect the system and network from the users. (You really are protecting the company's assets and reputation.) The level of trust given to users needs to vary greatly depending on the circumstances and fairly deciding that level while sufficiently protecting the organization's system without becoming Draconian is a lofty goal that is hard to achieve. It is harder even than getting the right amount of food and drink for a party.

On a large system with many users supporting important company functions such as order entry, accounting, or e-commerce, very few people should have the password to powerful accounts such as root or http or access that could "screw up" the system. No exceptions should be made for management. It is important for the SysAdmins to communicate well with each other and to others, such as the Database Administrators and Webmistress. (The Web server, Apache, should have its own account, http, rather than using the nobody account.)


All installations, configuration, reconfiguration, and backups should be made by careful and knowledgeable SysAdmins or their assistants. A mistake in any of these activities can cost the company many thousands or even millions of dollars.

On a personal workstation used mostly or exclusively by one person who is knowledgeable, it is probably okay to relax the rules but not do away with them. Even many knowledgeable Linux programmers do not worry about security either because "they are too busy trying to make a product deadline" or because they have not personally experienced a break-in and so think it is as overblown as the Year 2000 collapse of civilization.

Very, very few people will back up their personal computers anywhere near to the every two to seven days necessary to limit the losses of a mistake such as by typing

 
 rm * .o rm -rf / tmp/foo 

or a disk crash or theft. This is due to the inconvenience of most schemes. The following are a few solutions, some of which may work for your situation.

  1. Offer the Bourne shell script listed here to users to do secure remote backups. It will back up directories containing frequently changing data (/home, /var/spool/mail, and /etc) to a tape drive on a remote system. It will send e-mail containing any error messages to joe, the SysAdmin.

    Instead of writing to remote tape directly, it could store the backup in a disk file in a directory of backups and this directory could be backed up to tape periodically by standard methods. It is called rmtbackup1.

     
     #!/bin/sh # rmtbackup1 # Backs up /home, /var/spool/mail, and /etc # as relative paths onto remote system "central" # and sends status e-mail to joe@pentacorp.com. # # The v flag to tar may be removed to not list # file names in the e-mail. The O flag causes # the archive to be written to standard out. # # The e-mail will include any error messages. cd / tar -czvO --atime-preserve --totals home var/spool/mail etc \   | ssh -l backup central dd ibs=100k obs=100k of=/tmp/rmt0 \   | Mail -s "Backup from `hostname`" joe@pentacorp.com 

    This might require the manual keying of the ssh password each time this script is used. An alternative is to use a separate SSH passphrase just for this purpose with a nonroot account on the remote system that is dedicated to these backups. This remote user should have write access to the tape drive but not read access. This technique will limit the damage that could be done even if this on-disk password is viewed by a cracker. While this script will protect against network sniffing, the tape itself will not be encrypted. This can be done by inserting

     
     gpg -er recipient | 

    in the pipe before ssh. See "Encrypted and Signed Mail" on page 443 for more details.

    One possibility would be to use the mknod program to create other files with the same major and minor device numbers as /dev/rmt0. These other files each could be owned by a different group. One group could be called tapew and its file's mode could be 020. Accounts allowed to write to tape could be listed in this group's entry in /etc/group. All these files would have an owner of root to prevent anyone else from changing their permissions.


    One disadvantage of this remote tape technique is that it will not handle multiple tapes if this is necessary. If multiple tapes might be required, the dd command could be replaced with a call to this script, called dd_multi. The outer loop, started by the loop label, causes one gigabyte to be read from standard input and written to the /dev/rmt0 tape device. By using the obs variable to set the output block size, you force each output block to be 100 KB. Had you used a single bs variable, the blocking would be whatever it was when read from standard input. Because standard input likely will be a pipe or TCP network connection, this would have been essentially random.

    When the dd finishes writing 1 GB, it sends e-mail to the SysAdmin and does the inner loop, started with loop2, waiting for the SysAdmin to receive the e-mail and take action. If a full 1 GB was written, there is more data to be written so the SysAdmin should change tapes and issue the command

     
     touch /home/joe/dd_m 

    If, on the other hand, there were fewer than 10,000 records written, all data has been written. The SysAdmin should remove the tape and issue the command

     
     echo Done > /home/joe/dd_m 

    Clearly, the block size, amount of data to be written per tape, e-mail account, $flag path, and tape device all should be customized.

     
     #!/bin/csh -f # dd_multi # Copyright 2001 Bob Toxen. All rights reserved. # Email may be sent to book@verysecurelinux.com # May be distributed under the GNU public license # set email=joe@pentacorp.com set flag=/home/joe/dd_m set blksiz=100k set blocks=10000 # Reads stdin, copies 1 GB to tape, sends email to # to SysAdmin, waits for him to do #   "touch $flag" for next tape #   "echo done>$flag" if count was less than #     10000, indicating last tape. loop:          dd ibs=$blksiz obs=$blksiz count=$blocks of=/dev/rmt0 \            |& Mail -s "change tape, touch $flag" \            $email loop2:          if ( -f $flag ) then                   if ( -s $flag ) then                             /bin/rm $flag                             echo backup done | Mail -s "dd done" \                               $email                             exit 0                   endif                   /bin/rm $flag                   goto loop          endif          sleep 30          goto loop2 
  2. Use a central source repository, such as CVS, and have management require its use for program source and documents. Use a central database and Web server where applicable. Certainly, you will be backing up these central systems regularly.

  3. Use central systems for most of the important work, and have each user's personal system serve more as a X terminal with no important data, except possibly e-mail, either via pointing the central system's $DISPLAY variable at the user's system (wrapped in ssh, of course) or by using ssh to log in to the central system.

  4. Outfit users' systems with tape drives and you only need to worry about monitoring the crontab-triggered backups and tape swapping.

  5. The data on backup tapes should be strongly encrypted, if possible. If your tape backup software does not offer this capability, there are PGP and similar options that may be incorporated into backup procedures.

Off-site secure storage of backup tapes is absolutely critical. At many companies a single disgruntled engineer could come in on a Saturday night and destroy absolutely all of a company's data and backup tapes, and remove the unit that recorded his key code entry, removing all evidence of "whodunit." Follow the rule that no one person can destroy a substantial part of the company's data. This rule might be relaxed to trust a single SysAdmin doing the backups, depending on circumstances.

2.5.1 Dangers of Imported Software

graphics/fivedangerlevel.gif

Although there is lots of wonderful software on the Internet, there are also some Trojan horses lurking to take down the unwary, as well as buggy code. Consider the source (URL) where you get your software. If the same software is available from different trustworthy locations, download it from several and compare the results or compute the MD5 checksum and compare that checksum to the checksum published in several trusted places. Many sites and vendors now sign their software with PGP or the Free Software Foundation's GPG. Use one of these to validate the signature of what you downloaded. Red Hat's RPM package manager supports PGP-signed packages. If such a package passes the signature check, it can be trusted so long as the package creator's site has not been compromised.

Consider letting the downloaded software "sit" a few days or a week before even trying to build it and after that time, check the site again and see that the MD5 checksum did not change and that there were no notices of an intrusion, just in case someone did break into the site. If they do not provide a MD5 checksum, download the code a week later and compare.

When downloading from the author's site, take extra precautions as numerous crackers will try to break into the site and one may succeed in planting a Trojan horse. All the software on this site will be signed by the author's GPG key. The author's GPG public key is on the CD-ROM in the file:

 
 pubkey.txt 

"Signature Files" on page 441 explains how to use this key to verify that any files on the Web site are legitimate. Do not trust any files that do not pass this test.

2.5.2 Educating Users

graphics/fivedangerlevel.gif

Many nontechnical users know almost nothing about computers and certainly almost nothing about security. Most have only experienced Macs or Windows, which hide many details from all but the most curious users.

Take the time to explain some of the basic concepts such as the following:

  • Linux is designed to handle multiple users simultaneously.

  • Each user is identified by her account name.

  • Each account gets a unique number, similar to a customer number, called a User ID or UID.

  • Some accounts are grouped together into named groups, for example, the "users" group.

  • Each file is owned by one account and has permissions that determine which accounts may read from it, write to it, or, if it is a program, run it.

  • A set of files are collected into a directory (short for file directory). Directories are a lot like paper folders that can hold other documents. On Linux, directories are a lot like ordinary files with names, accounts that own them, and permissions that determine which accounts can have certain kinds of access to them.

  • It is important that the permissions on each file, including directories, be correct to prevent the wrong people from doing improper things with the file.

  • There are commands to list files' names, ownership, permissions, and sizes, to change file permissions, move them around, remove them, edit them, and copy them between systems. You might want to talk about ls, chown, mv, rm, vi or emacs, and ftp or ssh. This depends on what each user will be doing. In some cases a user simply may log in and invoke an application and "stay in" that application all day. Even in this case, unless it is a captive account that does not get a normal login shell, the user will want to know about e-mail and Netscape.

  • In an e-mail address or News posting, the sender's name and e-mail address can be faked (spoofed) easily and should not be trusted for important e-mail. Important e-mail needs to be verified by other trusted methods, such as PGP signatures or telephone, FAX, or paper mail contact to known good numbers or addresses.

A captive account is one where the person does not log in and use a normal shell. In many cases, the system would be configured to "drop" the person directly into an application, either by having the application listed as the login shell or by using an exec command, in each user's .profile or .cshrc file. Other captive accounts might allow access only via popd, pop3s, or Samba.



       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net