PAGEFLOP
FORWARD
SELECTOR
SELAGAIN
WRONGSEL
YOUR SELECTION IS NOT IN THE 0 - #SELIMIT RANGE Please try again
AANVANG
Copyright CourseWare Technologies, Inc. 1985-88
Lesson - 4
UNIX SYSTEM SECURITY
MENU
System Security|Topics to Learn|4-0|12,50
# Topic
--- -------
1 - System Security Considerations
2 - Controlling Passwords
3 - Consistency of Password and Group Files
4 - Sensitive Directories
5 - Controlling Default File Protection
6 - setuid Commands
7 - File Encryption and Decryption
8 - The Restricted Shell - rsh
9 - Lesson Review
0 - Return to the Main Menu
P1
System Security|System Security Considerations|4-1.1|14,52
As we mentioned in the UNIX User tutorial,
system security is important for several reasons:
1. to restrict access to sensitive information.
2. to prevent the copying or piracy of important
software; and
3. to prevent inexperienced users from making
changes or executing commands that may have
disastrous effects on their files as well as
the entire system.
P2
System Security|System Security Considerations|4-1.2|12,60
As a system administrator, you have several means
at your disposal to lessen the chance of system security
violations. You can:
* control logins with the /etc/passwd file,
* control access to certain directories with the
/etc/group file,
* control default file protections for sensitive files,
* restrict write permission in sensitive directories,
* use setuid to give root privileges to users
of certain commands when necessary,
* encrypt files, and
* set up a restricted shell - rsh so the user can
execute ONLY the commands you specify.
P3
System Security|Controlling Passwords|4-2.1|7,52
As we discussed in the System Administrator
tutorial, the file that holds all of the password
information is /etc/passwd.
By using the pwadmin command, a system
administrator can control how often users must
change their passwords and when they can do so.
You may want to write a shell script
or a command daemon that will force users to change
their passwords after a specified amount of time.
PWADMIN
P4
System Security|Controlling Passwords|4-2.2|13,54
To specify the number of weeks a password is
valid, append a comma and a letter after the encrypted
password, i.e.:
kjfdkjfkjds,L
The second letter after the comma indicates after how
many weeks a user may change the password.
If the password time constraints are applied,
the system adds two letters after the constraints to
indicate when the password was last changed.
P5
System Security|Consistency of Password and Group Files|4-3.1|14,54
UNIX provides you with the capability to
monitor the consistency of both the /etc/passwd
and the /etc/group files - the key user account
files.
The command for checking the password file is:
/etc/pwck
The command to check the group files is:
/etc/grpck
System Security|Consistency of Password and Group Files|4-3.1|13,54
UNIX provides you with the capability to monitor
the consistency of both the /etc/passwd and the
/etc/group files - the key user account files.
The command for checking the password file is:
/etc/pwcheck
The command to check the group files is:
/etc/grpcheck
P6
System Security|Sensitive Directories|4-4.1|7,52
A system administrator should be aware of two
types of sensitive directories:
* directories which certain users should not be
able to read and
* directories in which certain users should not be
able to write.
P7
System Security|Sensitive Directories|4-4.2|4,52
Allowing a non-trusted or inexperienced user
to have write permission in a directory would allow
that user to accidentally delete files in that
directory or write in a lot of irrelevant files!
P8
System Security|Sensitive Directories|4-4.3|15,52
Directories that should be write-protected include:
* the command directories: /bin, /usr/bin,
/usr/rbin, and /usr/ucb/bin;
* the system configuration directory: /etc;
* the device directory: /dev;
* the user directory: /usr;
* the library directory: /usr/lib; and
* the uucp setup directory: /usr/lib/uucp.
P9
System Security|Sensitive Directories|4-4.4|3,47
Furthermore, some files should not
even be readable by a user, in particular, the
security files or accounting information.
P10
System Security|Controlling Default File Protection|4-5.1|10,52
Many programs that alter the state of a file
have a default file protection for the files they
produce. For example, the editor will normally
produce a file with READ and WRITE privileges only.
A linker (if successful) will produce a file with
EXECUTE privilege as well.
As a system administrator, you can set up a
default mask for file protection on your system.
P11
System Security|Controlling Default File Protection|4-5.2|11,50
The command that is used for setting default file
protection is umask. It is the opposite of the chmod
command in that it lets you specify the permissions
which are to be removed. Like chmod, umask also uses
octal notation.
The difference between chmod and umask is
that chmod changes the protection for existing files
while umask changes the default protection for all
files created in the future.
P12
System Security|Controlling Default File Protection|4-5.3|14,52
Normally umask is set to 022, which gives the
owner read, write and execute permission and removes
the write permission from the group and others.
To make sure that the read AND write
permissions to the owners file are removed from
group and others, the umask command would be:
umask 066
The umask command with no arguments will
print the current setting.
UMASK
P13
System Security|setuid Commands|4-6.1|12,50
A command with setuid privilege is one that
allows the user to invoke the command with the same
permissions as the owner, usually the superuser.
If a program had a setuid system call when
it was compiled, then the setuid privilege takes
effect when the program is invoked.
Otherwise, as a superuser, you can set the user
ID with the chmod command.
P14
System Security|setuid Commands|4-6.2|8,48
A command with setuid privilege can be
recognized by using the ls -l command on the
/bin, /usr/bin, or other command directories.
You will see an s instead of an x as an
execute privilege for the owner. For example:
-rws--x--x 1 root 58368 /usr/ucb/lpq
-rws--x--x 1 root 51200 /usr/ucb/lpr
-rws--x--x 1 root 55296 /usr/ucb/lprm
---s--x--x 1 uucp 54272 /usr/bin/uucp
P15
System Security|setuid Commands|4-6.3|8,54
The advantage of using setuid is to give users
the same privileges as a superuser to do things like
check the status of devices, stop their own unwanted
print jobs, or activate and deactivate their own free
serial ports.
P16
System Security|setuid Commands|4-6.4|8,54
The disadvantage of using setuid is the potential
for a security breach if sensitive commands such as
chmod, chown, and others are run with setuid privilege.
You can see the potential danger for files like
/etc/passwd if users are allowed unauthorized modi-
fication of either the ownership or the access protection.
P17
System Security|File Encryption and Decryption|4-7.1|7,50
File encryption is a means for making files
unreadable. Only the user who encrypted the file should
have the key to decrypt it.
One must have a write permission on a file
in order to encrypt it.
P18
System Security|File Encryption and Decryption|4-7.2|7,52
The command for file encryption is crypt.
For example, the command:
crypt key < inputfile > outputfile
will encrypt the file inputfile and send the
result to the file outputfile!
P19
System Security|File Encryption and Decryption|4-7.3|6,47
The same key is used for decryption as
is used for encryption.
Once the file has been encrypted, the
original file should be deleted.
P20
System Security|File Encryption and Decryption|4-7.4|9,46
Although the encryption should be used with
discretion, it is useful when dealing with
non-trusted users.
If you want to make sure that no data is
transferred out of the system, good candidates
for encryption are: tar, cpio, dd, cu, uucp,
micnet, etc.
P21
System Security|File Encryption and Decryption|4-7.5|13,54
Even if the system is powered down and brought
up in a single-user mode and even if all passwords
and protections are altered, the encrypted programs
will not work, provided you deleted the originals!
Not to become a victim of your own game, make
sure you do not lose or forget the encryption
key/password!
Due to DOD restrictions, on several new releases
of UNIX the crypt command was deleted.
P22
System Security|The Restricted Shell|4-8.1|9,53
In a commercial environment where the programs
developed on your system have a real market value,
you are probably very concerned that these programs
may be copied, or that your methods may be exposed
to competitive or malicious users.
A way to reduce the possibility of a security
breach is by employing the restricted shell - rsh.
P23
System Security|The Restricted Shell|4-8.2|9,42
The restricted shell disallows:
* using cd to change directories,
* changing the shell variable PATH,
* using commands containing /, and
* redirecting output with > and <.
P24
System Security|The Restricted Shell|4-8.3|10,53
If a system administrator wants the user
george to have rsh as his login shell, the login
shell field in the /etc/passwd file must be
modified.
The next step is to modify the .profile or
the .login file in the restricted user's home
directory so that it puts the necessary restrictions
on the user.
P25
System Security|The Restricted Shell|4-8.4|12,54
To go a step further, you can choose commands
that a restricted user may execute by copying those
commands into the directories in the user's PATH
variable.
If you set up the restricted user's .profile
or .login file, make sure that he/she does not have
access to the sh or csh commands nor WRITE permission
on their .profile/.login file. Otherwise, all the
work in setting up the restricted shell becomes
meaningless!