Linux DevCenter    
 Published on Linux DevCenter (http://www.linuxdevcenter.com/)
 See this if you're having trouble printing code examples


O'Reilly Book Excerpts: Linux Security Cookbook

Secure Cooking with Linux, Part 2

Related Reading

Linux Security Cookbook
By Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes

by Daniel J. Barrett, Richard E. Silverman, Robert G. Byrnes

Editor's note: Last week's set of recipes from Linux Security Cookbook covered three basic security solutions to problems. This week, we offer recipes that fall into an intermediate-level category. Learn how to restrict access to network services by time of day, and how to use sudo to permit read-only access to a shared file.

Recipe 3.12. Restricting Access by Time of Day

Author's note: Most Linux systems control access to their network services using inetd or xinetd, two popular superdaemons. This recipe, excerpted from Chapter 3, "Network Access Control," demonstrates how to make inetd and xinet restrict access to those services depending on the time of day.

Problem

You want a service to be available only at certain times of day.

Solution

For xinetd, use its access_times attribute. For example, to make telnetd accessible from 8:00 a.m. until 5:00 p.m. (17:00) each day:

/etc/xinetd.conf or /etc/xinetd.d/telnet:
service telnet
{
        ...
        access_times = 8:00-17:00
}

For inetd, we'll implement this manually using the m4 macro processor and cron. First, invent some strings to represent times of day, such as "working" to mean 8:00 a.m. and "playing" to mean 5:00 p.m. Then create a script (say, inetd-services) that uses m4 to select lines in a template file, creates the inetd configuration file, and signals inetd to reread it:

/usr/local/sbin/inetd-services:
#!/bin/sh
m4 "$@" /etc/inetd.conf.m4 > /etc/inetd.conf.$$
mv /etc/inetd.conf.$$ /etc/inetd.conf
kill -HUP `pidof inetd`

Copy the original /etc/inetd.conf file to the template file, /etc/inetd.conf.m4. Edit the template to enable services conditionally according to the value of a parameter, say, TIMEOFDAY. For example, the telnet service line that originally looks like this:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

might now look like:

ifelse(TIMEOFDAY,working,telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd)

which means "if TIMEOFDAY is working, include the telnet line, otherwise don't." Finally, set up crontab entries to enable or disable services at specific times of day, by setting the TIMEOFDAY parameter:

0  8 * * * /usr/local/sbin/inetd-services -DTIMEOFDAY=working
0 17 * * * /usr/local/sbin/inetd-services -DTIMEOFDAY=playing

Discussion

For xinetd, we can easily control each service using the access_times parameter. Times are specified on a 24-hour clock.

For inetd, we need to work a bit harder, rebuilding the configuration file at different times of day to enable and disable services. The recipe can be readily extended with additional parameters and values, like we do with TIMEOFDAY. Notice that the xinetd solution uses time ranges, while the inetd solution uses time instants (i.e., the minute that cron triggers inetd-services).

See Also

xinetd.conf(5), inetd.conf(5), m4(1), crontab(5).

Recipe 5.11. Permitting Read-Only Access to a Shared File via sudo

Author's note: Sharing a file with multiple users is easy with Linux groups. But what if you want to restrict some people to have read-only access to a file, while giving others read/write access? This recipe, from Chapter 5, "Authorization Controls," explains how sudo can come to the rescue.

Problem

Two or more users want to share a file, some read/write and the others read-only.

Solution

Create two Linux groups, one for read/write and one for read-only users:

/etc/group:
readers:x:300:r1,r2,r3,r4
writers:x:301:w1,w2,w3

Permit the writers group to write the file via group permissions:

$ chmod 660 shared_file
$ chgrp writers shared_file

Permit the readers group to read the file via sudo:

/etc/sudoers:
%readers  ALL = (w1) /bin/cat /path/to/shared_file

Discussion

This situation could arise in a university setting, for example, if a file must be writable by a group of teaching assistants but read-only to a group of students.

If there were only two users -- one reader and one writer -- you could dispense with groups and simply let the reader access the file via sudo. If smith is the reader and jones the writer, and we give smith the following capability:

/etc/sudoers:
smith  ALL = (jones) NOPASSWD: /bin/cat /home/jones/private.stuff

then jones can protect her file:

jones$ chmod 600 $HOME/private.stuff

and smith can view it:

smith$ sudo -u jones cat /home/jones/private.stuff

See Also

sudo(8), sudoers(5), group(5), chmod(1), chgrp(1).

Check back here next week for recipes from Linux Security Cookbook on how to use PAM to restrict authentication on Linux systems, and how to use SMTP to securely accept connections from arbitrary clients.


Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.