DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Maintaining system security

Imported data

Files and filesystems brought into the system from elsewhere are a threat to the system if not handled properly. This section discusses techniques to use when importing files to your system.

Imported files

Do not take for granted the permissions on an imported file. Not only are the /etc/passwd and /etc/group files different on each system, but different security policies dictate setting different modes. These considerations are critical when the imported files are system files.

To minimize your intervention and clean up after importing files, train everyone on the system to use archive program options that do not reset ownerships. The files are owned by the user importing the files. The tar(C) and cpio(C) programs only preserve the ownerships of files loaded from an archive when invoked by the superuser. The archive programs generally reset the file modes to those described on the media containing the archive. In addition to having a mode that is more permissive than necessary, files can have SUID, SGID or sticky bits set. All of these situations can create security problems for you.

To minimize the effects of the archive permissions, use archive options that examine the contents without extracting anything. For example, the tv option to tar and the -itv option to cpio let you see the modes of the files on tape and prepare for any ill effects when extracting files. When bringing in unfamiliar archives, first import files into a hierarchy not accessible to others. Then move the files, after adjusting the ownership and modes according to your system policy.

Imported filesystems

Mounting filesystems (including floppy disk filesystems) that were created or handled elsewhere raises all the same concerns as importing files. Filesystems also bring additional concerns:

In either case, mounting a corrupted filesystem can cause the system to crash, the data on the imported file system to be further corrupted, or other filesystems to suffer damage from side effects. This is why the mount(ADM) command is reserved for the superuser. Read/write filesystems should always be checked with fsck(ADM) before they are mounted. If the filesystem contains system files, the integrity(ADM) and fixmog(ADM) utilities should also be run after it is mounted.

Mounted filesystems can contain unacceptable file permissions. The superuser of the imported filesystem may have set ownerships, sticky bits, special files, SUID/SGID bits, and file tree compositions incompatible with your system policies.

Administrators should consider very carefully which filesystems users are allowed to mount with the mnt(C) command. It is possible to circumvent system security after mounting a filesystem created in a separate administrative domain. For this reason, users should not be allowed to mount filesystems from devices which are removable, such as floppies, CD-ROMs, removable hard drives, and so forth. This could be used to introduce an SUID root binary created elsewhere.

Use the nosuid option with the mount(ADM) command to ignore SUID bits on an NFS or CD-ROM filesystem. Only those NFS filesystems that are controlled by the same set of superusers should be excepted from this recommendation.

You can also use the -s option to ncheck(ADM) to locate any potentially dangerous SUID files before mounting. Filesystems, like files, should be scanned before they are mounted. The first time a filesystem is mounted in your control, it is best to mount it in a private directory so you may scan the filesystem manually before mounting it in its normal place. Examine the file organization, the owners and modes of the files, and the expected use of the filesystem.


Next topic: Terminal escape sequences
Previous topic: Data encryption

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 03 June 2005