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 firstname.lastname@example.org 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 email@example.com 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 (firstname.lastname@example.org) 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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide