Author: Brian Jones
administrators can now take advantage of some of the benefits of network groups
without the overhead of maintaining a NIS server. In this article, I’ll explain what netgroups are, and how they can help you get finer-grained control over your local system security.Netgroups came along as part of Sun’s Network Information Service (NIS) naming service. The administrator community soon discovered their utility and pressured the developers
of the underlying glibc and NSS libraries to support looking up basically
anything in nsswitch.conf from any service (NIS, LDAP, files, or otherwise).
Netgroups are not the same as normal POSIX groups. For one thing, netgroups
don’t have to have anything at all to do with users. You can have netgroups that
represent groups of hosts as well. This feature, however, also comes with a
slight increase in complexity in terms of how netgroups are defined. With a
normal group, you have a record in your NIS group map or /etc/group file that indicates the group name, a password (which
is usually not used in many environments), the numeric group ID, and then a
comma-delimited list of users that belong to the group. A typical POSIX group
entry looks like this:
wheel:x:10:joe,karen,tim,alan
Netgroups, on the other hand, are defined as “triples” in a netgroup NIS map, or in an LDAP directory; three fields,
representing a host, user and domain — in that order. All three are optional. Let’s have a look:
trustusr (-,steve,) (-,jonesy,)
trusthost (deathstar,-,) (falcon,-,)
The “trustusr” netgroup consists of two users, steve and jonesy. We know that
they are users because the names are in the middle field of the triple. The
“trusthost” netgroup consists of two hosts, deathstar and falcon. We know that
they’re both hosts because their names are in the first field. The last field in
a netgroup triple is reserved for a domain name. If you’re using NIS, your clients bind to a domain, and this field becomes more meaningful. For users
storing the triples in an LDAP directory, you don’t bind to a domain, so this
field doesn’t need to be used.
Let’s have a quick look at a couple of areas where netgroups can
be put to effective use. Of course, if you’re an administrator who is making the
slow, painful migration from NIS to LDAP, one clear benefit to using netgroups is not having to
reconfigure all of the clients that [are defined in them?], but there are
many others.
The TCP Wrappers configuration files
The /etc/hosts.allow and hosts.deny files support a package called TCP Wrappers that helps
administrators define a fairly robust security configuration for a given host.
TCP Wrappers lets you can monitor and filter incoming requests for several network services. The software essentially intercepts connection attempts, checks the attributes of
the connection (source, service, user, etc.) against the configuration files,
and allows or denies connections accordingly. TCP Wrappers configuration can
get somewhat complex, and is outside the scope of this article. If you need
help with it, you can enter the shell command man 5 hosts_access.
Let’s look at typical host.allow and hosts.deny files that don’t use netgroups and compare them to an equivalent hosts.allow that does. The typical files look something like:
#
# hosts.allow
#
in.cfingerd:ALL
portmap:ALL
ALL:192.168.2.,192.168.3.,.linuxlaboratory.org EXCEPT
badhost.linuxlaboratory.org, opus, willy
#
# hosts.deny
#
ALL:ALL
Our hosts.allow file says to allow access to the finger daemon and portmap to
anyone. However, there are apparently other daemons running on this machine, and
the only hosts allowed to access these other services are (in order):
- Any host in the 192.168.2 or 192.168.3 subnets.
- Any host in the linuxlaboratory.org domain (except for badhost), and
- hosts “opus” and “willy.”
That’s a lot of typing, with a lot of room for typos, it takes a lot of parsing to read it. This configuration also leaves some room for extra hosts to get by who you
had no intention of giving access to. For example, if you add a new host to the
linuxlaboratory.org domain, it automatically has access to all the services
on this machine.
How about making a host netgroup that contains only the hosts
that need access to all of the services, and referencing that in the hosts.allow
file? Here’s what it might look like:
goodhosts (opus,-,)(willy,-,)(cartman,-,)(stan,-,)(chef,-,)
You’ll recognize opus and willy from the original hosts.allow file. The other
hosts are those in the linuxlaboratory.org domain that need access to
all services available on this machine. Now we can rewrite that nasty ALL line
in our hosts.allow file:
#
# hosts.allow
#
ALL: @goodhosts,192.168.2.,192.168.3.
This is much easier to read, has less room for typos, and is a more restrictive
security policy, since hosts have to be explicitly added to the netgroup to gain
access, instead of inheriting access by virtue of their existence in something
as large as a whole domain.
Netgroups and “compat mode”
Compat mode (short for “compatibility”) lets you add NIS/NIS+ compatibility to an /etc/passwd or /etc/shadow file. It’s pretty neat stuff, and netgroups make it especially cool.
Let’s look at how to use netgroups and compat mode. First, define
a user netgroup in LDAP or NIS or files — whichever you use — that contains only our most trusted users:
trustme (-,larry,)(-,curly,)(-,mojo,)
Next, we put an entry for this netgroup into our /etc/passwd file. Here’s what
the line looks like:
+@trustme
This effectively adds all of the users in the trustme
netgroup to the /etc/passwd file. Now we just set up our /etc/nsswitch.conf file
to use compat mode, which is what supports the parsing of the “+@” syntax in
the /etc/passwd file:
passwd: files compat
passwd_compat: ldap
In the first line, we tell the system we’re using files with compat mode to
look up passwd information on a user. The second line tells us which naming
service the compat mode information request is to be sent to. In our case,
having files compat allows for a root account that’s local to each
machine and lives in the /etc/passwd file, while still allowing us to make use
of an LDAP server for non-local accounts which are centrally maintained.
In closing
This is not an exhaustive list of uses for netgroups. They can be used for
other things as well, not the least of which are things like your NFS exports
file and other fields of your nsswitch file. Since netgroups have been around
since the last Ice Age, many utilities at the system level already know what
they are. Currently Linux has, by far, the best support for requesting
netgroups from an LDAP server. The libraries that do the heavy lifting for
Linux (OpenLDAP and PADL’s nss_ldap) can also be installed on most Unix flavors
— good news for those of us in heterogenous environments!
