 | There may be mechanisms and methods under other versions of Unix for restricting accounts and managing dormant accounts. We present the most common methods in this section of the book. | | Some systems have the ability to restrict the circumstances under which each user may log in. In particular, you could specify times of day and days of the week for each account during which a user may not log in. You could also restrict the login account to a particular terminal line. These features are also available through the Pluggable Authentication Modules (PAM) module pam_time . These restrictions are useful additional features to have, if they are available. They help prohibit access to accounts that are used only in a limited environment, thus narrowing the "window of opportunity" an attacker might have to exploit the system. For example, if your system is used in a business setting, perhaps the receptionist will never log in from any network terminal, and he is never at work outside the hours of 7:00 a.m. to 7:00 p.m. on weekdays. Thus, you could configure his account to prohibit any logins outside those terminals and those hours. If an attacker knew the account existed and was involved in password cracking or other intelligence gathering over an off-site network connection, she would not be able to get in even if she stumbled across the correct password. If your system does not support this feature yet, you can ask your vendor when it will be provided. If you want to put in your own version, you can do so with a simple shell script: [5] [5] This script should work on most Unix systems with POSIX-compliant Korn shells , but may require modification for older ksh versions. -
First, write a script like the following and put it in a secure location, such as /etc/security/restrictions/fred : #!/bin/ksh allowed_ttys="/dev/tty@(010203)" allowed_days="@(MonTueWedThuFri)" allowed_hours="(( hour >= 7 && hour <= 19))" real_shell=/bin/ksh my_tty="$(/bin/tty)" dow="$(/bin/date +%a)" hour=$(/bin/date +%H) eval [[ $my_tty != $allowed_ttys ]] && exit 1 eval [[ $dow != $allowed_days ]] && exit 1 eval $allowed_hours exit 1 exec -a -${real_shell##*/} $real_shell ${1+"$@"} -
Replace the user's login shell with this script in the /etc/passwd file. Do so with the usermod -s command, the vipw command, or equivalent: # usermod -s /etc/security/restrictions/fred fred Remove the user's ability to change his or her own shell. If everyone on the system is going to have constraints on login place and time, then you can simply specify: # chmod 0 /bin/chsh This method is preferable to deleting the command entirely because you might need it again later. [6] [6] Be very careful when running this command, as it will work only if /bin/chsh is a single-purpose program that only changes the user's shell. If passwd is a link to chsh (or other password utilities), the chmod can break a lot of things. On many Unix systems, /bin/passwd is a hard link to /bin/chsh , so if you do this chmod , people won't be able to change passwords either! Note as well that removing chsh won't work in this case because users can ln -s /bin/passwd chsh and run it that way. Finally, some passwd programs have the chsh functionality as a command-line option! On these systems, you can only prevent a user from changing his shell by removing the unapproved shells from the /etc/shells file. If only a few people are going to have restricted access, create a new group named restricta (or similar), and add all the users to that group. Then, do the following: # chmod 505 /bin/chsh # chgrp restricta /bin/chsh This will allow other users to change their shells, but no one in the restricta group will be able to do so. | | If you take this approach, either with a vendor-supplied method or something like the example above, keep in mind that there are circumstances in which some users may need access at different times. In particular, users traveling to different time zones, or working on big year-end projects, may need other forms of access. It is important that someone with the appropriate privileges be on call to alter these restrictions, if needed. Remember that the goal of security is to protect users, and not get in the way of their work! | | |
