USERS
Many BSD systems have a large user base, and the BSD system administrator often needs to perform a specialized task for multiple users. The BSDP candidate must be able to configure user accounts and to automate many tasks associated with user account management.
3.4.1. Customize the login class capability database.
Importance: 3.3, Frequency: 1.6, Bloom: K,C,A
Concept:
Part of the login(1) process is to check various attributes in the login class capability database to see if the current login should be permitted or denied.
BSDP candidates should understand the capabilities offered by the login class database and be able to configure a login class.
Practical:
login(1), login.conf(5)
DragonFly BSD, FreeBSD: login.access(5)
OpenBSD: authenticate(3), bsd_auth(3)
Estimated Time:
15 minutes to configure and test a user account in the login capability database.
3.4.2. Script the creation/deletion/ modification of multiple user accounts.
Importance: 3.3, Frequency: 1.8, Bloom: K,A
Concept:
Manually adding, deleting, and modifying individual user accounts is practical when the number of users is small. However, it is often easier to create a script to perform basic account management operations for large numbers of users.
BSDP candidates should be able to script the creation, deletion, and modification of user accounts using their scripting language of choice.
Practical:
scripting language of choice
adduser(8), rmuser(8) or userdel(8), usermod(8) or vipw(8)
Estimated Time:
15 minutes to create and test user accounts modified by a script according to a specification.
3.4.3. Prevent regular users from viewing who is logged on and seeing what others are doing.
Importance: 3.5, Frequency: 1.8, Bloom: K,C
Concept:
Some BSD systems provide kernel MIBS which can be used to prevent users from snooping on each other. Additionally, SSH users can be constrained to their own chroot environment.
BSDP candidates should be able to configure their BSD system to prevent users from seeing the activities of other users.
Practical:
sshd_config(8)
FreeBSD: sysctl(8)
NetBSD: sysctl(7)
Estimated Time:
5 minutes to configure the system to prevent users from viewing the activities of other users.
3.4.4. Restrict the commands available to a user.
Importance: 3.7, Frequency: 1.9, Bloom: K,C,A
Concept: reworded so applies to all BSDs
One way to increase the security of a system is to restrict the commands that are available to logged-in users. This can be achieved through the installation and configuration of a restricted shell or by adding commands to the user's SSH authorized_keys file.
BSDP candidates should be able to restrict the commands available to a given user.
Practical:
software of choice from packages/pkgsrc
sshd(8)
Estimated Time:
20 minutes to configure a restricted shell according to a specification.
3.4.5. Create or modify skeleton files for new user's home directories.
Importance: 3.5, Frequency: 1.7, Bloom: K,A
Concept:
It is possible to automatically populate the home directories of new users with “dot” files. These files can be preconfigured with aliases, environment variables, and shell functions.
BSDP candidates should be able to configure a skeleton “dot” file and have it populate the home directories of new users automatically.
Practical:
shell configuration file(s) of choice
/skel/ directories on BSD of choice
Estimated Time:
15 minutes to configure and test skeleton files for new user accounts according to a specification.
3.4.6. Force an active user off the system.
Importance: 3.6, Frequency: 1.8, Bloom: K,A
Concept:
It is sometimes necessary to force malicious users off the system.
BSDP candidates should be able to force a specified user off the system and prevent them from regaining access.
Practical:
ps(1), kill(1), pkill(1), hosts_access(5), hosts_options(5), vipw(8)
DragonFly BSD, FreeBSD: pw(8)
NetBSD, OpenBSD: usermod(8)
Estimated Time:
5 minutes to force a user off the system and configure the system to disallow logins for that user.
3.4.7. Set shell limits.
Importance: 3.6, Frequency: 1.9, Bloom: K,A
Concept:
A user's shell can be configured to limit the number of open files, the number of blocks for core dumps, and other similar limits.
BSDP candidates should be able to configure shell limits for their shell of choice.
Practical:
man page for shell of choice
Estimated Time:
15 minutes to configure and test shell limits according to a specification.
3.4.8. Configure resource limits.
Importance: 3.5, Frequency: 1.8, Bloom: K,A
Concept:
BSD systems use login.conf(5) to limit resources such as CPU and memory usage.
BSDP candidates should understand the difference between hard and soft limits, be able to create a login class, and add resource limits to that class.
Practical:
login.conf(5)
Estimated Time:
5 minutes to tune resource limits according to a specification.
3.4.9. Generate a key and configure the system to use it for SSH authentication.
Importance: 4.3, Frequency: 2.4, Bloom: K,C,A
Concept:
SSH key based authentication is a secure method for authenticating remote users.
BSDP candidates should be able to configure, install, and test SSH keys for authentication, troubleshoot authentication problems, and change key formats between OpenSSH and RFC 4716.
Practical:
ssh-keygen(1), sshd(8), sshd_config(5)
Estimated Time:
20 minutes to generate, install, and test a key for SSH authentication.
3.4.10. Configure users to autologout after a period of inactivity.
Importance: 3.3, Frequency: 1.7, Bloom: K,A
Concept:
Setting an idle timeout on user sessions is a best practice. The method for configuring autologout of users is shell dependent and should be enforced at the system level.
BSDP candidates should be able to configure autologout for their shell of choice.bash, ksh, csh, and tcsh at a minimum.
Practical:
man page for shell of choice
Estimated Time:
15 minutes to configure and test autologout according to a specification.
3.4.11. Log a user's activity on a terminal.
Importance: 3.3, Frequency: 1.7, Bloom: K,A
Concept:
Logging all user input and terminal output is desirable in many situations.
BSDP candidates should be able to configure a user login to record all user activity on a terminal.
Practical:
script(1), configuration file for shell of choice
Estimated Time:
10 minutes to configure and test a shell to log all activity according to a specification.
3.4.12. Configure a user account to expire on a specified date.
Importance: 3.2, Frequency: 1.7, Bloom: K,A
Concept:
User accounts can be created or modified to expire on a certain date.
BSDP candidates should understand account expiration capabilities and be able to configure and test and user account expiration.
Practical:
adduser(8) or useradd(8), login.conf(5)
DragonFly BSD, FreeBSD, NetBSD: pw(8)
Estimated Time:
10 minutes to configure a user account to expire according to a specification.
3.4.13. Create a system account.
Importance: 3.8, Frequency: 2.2, Bloom: K,A
Concept:
System accounts are those that are created for use by applications, and for security reasons, should not be available for users to login to the system. These accounts do not need a login shell and generally do not need resources.
BSDP candidates should be able to create and test a system account.
Practical:
adduser(8) or useradd(8), nologin(8)
Estimated Time:
10 minutes to create and test a system account according to a specification.