8.3 Restricting Logins

Some systems have (or will soon 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 restrictions are very useful additional features to have, if they are available. They help prohibit access to accounts that are only used 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 VP of finance will never log in from any network terminal, and he is never at work outside the hours of 7 a.m. to 7 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:

1. First, write a script something like the following and put it in a secure location, such as /etc/security/restrictions/fred:

   #!/bin/ksh
   
   allowed_ttys="/dev/tty@(01|02|03)"
   allowed_days="@(Mon|Tue|Wed|Thu|Fri)"
   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+"$@"}

2. 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

3. 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:

   # chmod 0 /bin/chsh

   This method is preferable to deleting the command entirely because you might need it again later.[3]

   [3] Be very careful when running this command as it will only work 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. Under SunOS, 4.1.x, /bin/passwd is a hard link to /bin/chfn, so if you do this chmod, people won't be able to change passwords either! (This may be the case for other operating systems as well.) Note as well that removing chsh won't work either in this case because users can ln -s /bin/passwd chfn and run it that way. Finally, some passwd programs have the chfn 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:

   #   chmod 505 /bin/chsh # chgrp restricta /bin/chsh

   This will allow other users to change their shells, but not anyone in the restricta group.

NOTE: If you take this approach, either with a vendor-supplied method or something like the example above, keep in mind that there are circumstances where 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 is 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!