Detections
Analytics

4.1.2.1 Ensure at is restricted to authorized users

Information

The at utility allows some moderately complex time specifications. It accepts times of the form HHMM or HH:MM to run a job at a specific time of day. (If that time is already past, the next day is assumed.) As an alternative, the following keywords may be specified: midnight, noon, or teatime (4pm) and time-of-day may be suffixed with AM or PM for running in the morning or the evening. The day on which the job is to be run may also be specified by giving a date in the form month-name day with an optional year, or giving a date of the forms DD.MM.YYYY, DD.MM.YY, MM/DD/YYYY, MM/DD/YY, MMDDYYYY, or MMDDYY. The specification of a date must follow the specification of the time of day. Time can also be specified as: [now] + count time-units, where the time-units can be minutes, hours, days, weeks, months or years and at may be told to run the job today by suffixing the time with today and to run the job tomorrow by suffixing the time with tomorrow.

For example, to run a job at 4pm three days from now, use at 4pm + 3 days, to run a job at 10:00am on July 31, use at 10am Jul 31 and to run a job at 1am tomorrow, use at 1am tomorrow.

The superuser may use these commands in any case. For other users, permission to use at is determined by the files /var/at/at.allow and /var/at/at.deny.

If the file /var/at/at.allow exists, only usernames mentioned in it are allowed to use at. In these two files, a user is considered to be listed only if the user name has no blank or other characters before it on its line and a newline character immediately after the name, even at the end of the file. Other lines are ignored and may be used for comments.

If /var/at/at.allow does not exist, /var/at/at.deny is checked, every username not mentioned in it is then allowed to use at.

If neither exists, only the superuser is allowed use of at. This is the default configuration.

On many systems, only the system administrator is authorized to schedule at jobs. Using the at.allow file to control who can run at jobs enforces this policy. It is easier to manage an allow list than a deny list. In a deny list, you could potentially add a user ID to the system and forget to add it to the deny files.

Solution

Run the following script to:

 - /var/at/at.allow :
 - Create the file if it doesn't exist
 - Change owner or user root or daemon
 - Change group to wheel
 - Change mode to 640 or more restrictive

 - -IF- /var/at/at.deny exists:
 - Change owner or user root
 - Change group to wheel
 - Change mode to 640 or more restrictive

#!/bin/sh

{
 [ ! -e "/var/at/at.allow" ] && touch /var/at/at.allow
 chown root:wheel /var/at/at.allow
 chmod u-x,g-wx,o-rwx /var/at/at.allow
 [ -e "/var/at/at.deny" ] && chown root:wheel /var/at/at.deny
 [ -e "/var/at/at.deny" ] && chmod u-x,g-wx,o-rwx /var/at/at.deny
}

See Also

https://workbench.cisecurity.org/benchmarks/19044

Item Details

Category: ACCESS CONTROL, MEDIA PROTECTION

References: 800-53|AC-3, 800-53|AC-5, 800-53|AC-6, 800-53|MP-2, CSCv7|14.6

Plugin: Unix

Control ID: c05e58c5c28e56c3d42b1b68c32cdb54631ab2bc970ea23df1883b89465cee90