System Administation: Maximizing System Security, Part 1
In some circumstances, you may want to use some means of determining that a user is who she says she is in addition to standard passwords. To address such a need, the shadow package also supports entries like the following in /etc/shadow:
When user chavez logs in, she is prompted for her password, and then the program /sbin/extra runs as a secondary authentication program. This program, supplied by the system administrator, can perform whatever sort of additional authentication is desired, returning a value of 0 or 1 depending on whether the user has passed or failed. The second entry indicates that user harvey runs /sbin/extra as his only authentication method. In the shadow file syntax, the @ sign introduces the alternate or additional authentication program, and a semicolon is used to separate it from the encoded password.
The final feature of the shadow package we consider is its dialup password facility, which allows you to require an additional password from users who connect to the system via a dialup line. When this feature is enabled, two additional configuration files are used, /etc/dialups and /etc/d_passwd. /etc/dialups contains a list of special filenames for serial lines that are to be protected with an additional password whenever someone dials into the system (one per line), and /etc/d_passwd holds the encoded dialup passwords.
Dialup passwords are assigned on a shell-by-shell basis, and the dpasswd command is used to create and change them. For example, the following command will allow you to change the current dialup password for the shell /bin/bash:
# dpasswd /bin/bash
Dialup passwords will not be required from users using shells that are not listed in /etc/d_passwd.
One of the biggest weaknesses with UNIX security in general is its all-or-nothing approach to system privilege: root is powerful, so it is only prudent to limit access to the root account as much as possible. The sudo facility enables non-root users to run specified commands as root without having to know the root password, allowing a system administrator to provide users with just the level of access they actually need.
A user uses the facility by prefacing the command he wants to run with the sudo command:
$ sudo mount hamlet:/data /mnt
:sudo will require the user to enter his own password before completing the command. Thus, in this case, using sudo allows this user to use the mount command without knowing the root password.
Access to sudo is controlled by its configuration file, /etc/sudoers. This file specifies which users can use sudo along with the commands they are allowed to execute. Here is a small extract from such a file:
chavez ALL=ALL harvey ALL=/bin/mount,/bin/umount nelson ALL=!/sbin/shutdown
Usernames are the first field in each entry, followed by one or more access description strings which have the general form: host(s)=command(s). Based upon these entries, user chavez can use sudo to run any command on any system, user harvey can mount and unmount disks, and user nelson can run any command except shutdown. Note that these examples represent only the simplest form of this file; its actual syntax is very flexible and powerful, allowing you to define named groups of hosts and/or commands and thereby specify exact access for each user-host-command combination in as much detail as necessary.
Practical Internet and UNIX Security, (2nd edition of Practical UNIX Security), Simson Garfinkel and Gene Spafford (O'Reilly & Associates, late 1995 or early 1996). An excellent book-length treatment of system security and the associated system administrative concerns and tasks.
Essential System Administration, 2nd edition, Æleen Frisch (O'Reilly & Associates, 1995). A substantial chapter is devoted to system security, as are numerous additional sections throughout the book.
Firewalls and Internet Security, William R. Cheswick and Steven M. Bellovin, (Addison-Wesley, 1994); Building Internet Firewalls, D. Brent Chapman and Elizabeth D. Zwicky (O'Reilly & Associates, 1995). Two essential books for anyone considering setting up a firewall system.
Security Alerts Mailing Lists
The Computer Emergency Response Team (CERT) manages the primary UNIX-related security-alert system. Send mail to email@example.com to be added to the mailing list. Past advisories and updates are available via anonymous ftp at info.cert.org:/pub/cert_advisories.
There is also a Linux-specific security advisory mailing list. Send mail to firstname.lastname@example.org with subscribe linux-alert in the body of the message to be added to the list. You may also want to subscribe to the linux-security mailing list, which is a moderated discussion list for Linux-related security topics. (To subscribe, include subscribe linux-security in the body of a message to the same email address.) The archives for these mailing lists are available via anonymous ftp at linux.nrao.edu:/pub/linux/security/list-archive.
Æleen Frisch (email@example.com) manages a very heterogeneous network of Linux and other UNIX systems and PCs. Having recently finished second editions of two books, she looks forward to pursuing her true calling: pulling the string for her cats, Daphne and Sarah.
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python