Networks often require access restrictions based on time. The system administrator may not want a particular service to be accessed on weekends, or a traveling user may need access to a filesystem when he/she is working in another time zone. In this Daily Feature article, I will discuss ways to use Pluggable Authentication Modules (PAM) to allow and deny access to system services, based on time.
The pam_time module
The pam_time module is used as an account module-type. The pam_time module does not accept arguments. It instead uses the /etc/security/time.conf file to get information related to login time and location restrictions. There are two important points concerning the /etc/security/time.conf.
- If the /etc/security file does not exist, there are no login restrictions related to login time or location.
- The limitations set by /etc/security apply to all users, including root.
The /etc/security/time.conf file restricts access by time and location when used with pam_time. Each line in /etc/security/time.conf file is called a rule. Each rule uses the following syntax:
services;ttys;users;times
Table A describes the function of each of these entries.
Entry | Function |
services |
Used to list services used with PAM. Several records may be used with the same service. |
ttys | A list of devices that may be allowed or denied access. |
users |
A list of users who are known to the system. This list may include root. |
times | A list which determines the times when a specific rule applies |
Logical operators
Logical operators are special characters used to apply conditions to parameters in configuration files and scripts. Table B lists the logical operators used in /etc/security/time.conf, and other configuration files.
Operator | Function | Typical Use | Description |
& | Logical AND | jack & jill. |
This rule applies to the users jack and jill. |
| | Logical OR | ftp | telnet. |
This rule applies to ftp or telnet. |
! | Logical NOT | ! ssh. |
This rule does not apply to the secure shell. |
* | Wildcard |
This is used when a match for any value is required. |
Time codes
Time codes are used to establish the times when access rules are in effect. Time codes may specify either the day of the week or the time of day when a rule is in effect, or both.
When establishing time of day restrictions, time is measured using a 24-hour clock. If a restriction is required for 1:00 P.M., the time used in the configuration file would be 1300, since 1:00 P.M. is the thirteenth hour of the day. Table C lists the day codes used in configuration files.
Day code | Function |
Su, Mo, Tu, We |
These are the codes used for the days of the week, beginning at Sunday, and ending with Saturday. These codes may be used in a continuous text string to represent multiple days. SuTuFr would indicate a restriction is in place on Sunday, Tuesday, and Friday. |
Wk, Wd |
Wd signifies weekdays. Wk signifies weekends. The string SuWk means all weekends except Sundays. The string WeWd means all weekdays except Wednesdays. |
A1 |
This term signifies all seven days of the week. The string A1Th means all days of the week, except Thursdays. |
Putting /etc/security/time.conf to work
Below you will see a sample /etc/security/time.conf file. Remember, the format for entries in this file is:
services; ttys; users; times
A simple /etc/security/time.conf file will look like:
*;tty1;jim;A10000-2300
login & ssh;*;jane | jim|bill|susan;A11200-2000
ftp;*;guest;MoTuFr0800-1700&!Wk0000-2400
finger;*;guestA10000-2400
Now, let’s examine the contents of this file. The first line:
*;tty1;jim;A10000-2300
allows the user Jim access to all services from midnight until 11:00 P.M., as long as Jim is logging from tty1.
The second line:
login & ssh;*;jane | jim|bill|susan;A11200-2000
allows the users Jane, Jim, Bill, and Susan access to the system on any day of the week—from 12:00 noon until 8:00 P.M.—as long as they are accessing the system using /bin/login, or the secure shell, ssh.
The third line:
ftp; *;guest;Wk0000-2400
allows the user guest access to the system via FTP at any time during the weekend.
The last line:
finger;*;guestA10000-2400
prevents the user from obtaining finger information from the system at any time.
Test yourself
What would happen if I placed the following entry in /etc/security/time.conf?
*;*;*;!A10000-2400
If you guessed that this entry would deny access to all users, including root, you’re right. The point here is to be very careful when making modifications to the time.conf file. Always make a backup copy of this file before any modifications are made.
The purpose of the /etc/security/time.conf file is to restrict access. If entries in this file contain overlapping times or locations, the entry granting the least access is used. Place a pam_time entry in the /etc/pam.d configuration file for each application requiring restricted access.
Restricting access based on system resources
Setting limits on the system resources available to each user may also restrict system access. Placing limits on system resources provides two distinct advantages for the system administrator:
- No single user or service will consume available resources, avoiding bottlenecks.
- Limits on system resources are useful in preventing system-based DoS attacks.
PAM uses two components to establish limits on system resources: the pam_limits module, and the /etc/security/limits.conf file. The pam_limits module may be used as a session module-type only. The pam_limits will accept only two arguments:
- debug—used to send information to syslog
- conf=path-to-config-file—The default for this argument is /etc/security/limits.conf.
The /etc/security/limits.conf file establishes system resource limits on a per-user or per-group basis. All limits set by the limits.conf file apply to a single session. Total limits are set on system resources by restricting the maximum number of concurrent user logins. Entries are made to /etc/security/limits.conf using the format:
Username or groupname, hard-or-soft limit, limited-resource, limit-value
Table D lists the special characters and syntax used in /etc/security/limits.conf.
Character or syntax | Function |
# | Used to specify comments |
@groupname | Groupnames are always preceded by the @ character |
* |
Wildcard character. Used to represent all users or all groups |
Hard / soft |
Denotes a hard or soft limit on a specific resource. A hard limit sets a fixed limit. A soft limit uses a default limit. |
– | Used to establish limits for a specific user |
Table E shows a typical /etc/security/time.conf file.
User/group | Limit-type | Resource | Limit-value |
* | hard | stack | 10000 |
@finance | hard | nofile | 10 |
@accounting | hard | fsize | 2000 |
jim | – | ||
ftp | hard | maxlogins | 50 |
Now, let’s examine the restrictions set by these entries. The first line:
*, hard, stack,10000
sets a stack limit of 10,000 kilobytes, or 10 MB, for all users.
The second line:
@finance, hard, nofile 10
specifies that users in the finance group may have a maximum of 10 open files.
The third line:
@accounting, hard, fsize, 2000
sets the maximum file size for users in the accounting group to 2 MB.
The fourth line:
jim -,
disables all restrictions for the user Jim.
The last line:
ftp, hard, maxlogins, 50
sets the maximum number of concurrent FTP logins to 50.
Restricting /etc/security/time.conf
Table F shows the resources that may be restricted using the /etc/security/time.conf file. The only way to properly implement these, or any restrictions, is to know the requirements of your network. Remember, any security restrictions you apply to your system will result in a user being unable to perform a task. Restrictions should always be tested before being implemented on a production server.
Resource | Function |
Core | Limits the size of core files |
Fsize | Sets maximum file size |
Data | Maximum data size |
Nofile | Maximum number of open files |
Cpu | Maximum CPU time in minutes |
Stack | Maximum stack size |
Nproc | Maximum number of processes |
As | Used to limit address space |
Maxlogins | Maximum number of concurrent logins |
Memlock | Maximum locked-in memory address space |
Rss | Maximum resident set size |
Summary
In this article, I discussed ways of using PAM to enforce a system access policy based on time. I explained the PAM modules and configuration files required to enforce this policy, and the procedures required to modify these files. I also showed you some entries that should not be used by administrators when establishing a time-based system access policy.
Jim McIntyre, retired from the Canadian navy, has a total of 12 years of IT training and experience, as well as extensive technical support experience. Jim completed the Novell CNE program, the Adult Education program at Saint Francis Xavier University, and the Webmaster Program at Dalhousie University. His hobbies include golf and hiking.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.