NIS+ part 1: What's in a Name (Service)?
It's not popular, but NIS+ offers noteworthy security features
September 1996
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
NIS+ part 1: What's in a Name (Service)?It's not popular, but NIS+ offers noteworthy security features |
September 1996
|
Adoption of NIS+ has been slow (to put it mildly). True, NIS+ was introduced poorly by Sun. The latest releases have turned it into a solid naming system that vastly improves security over NIS. This month we look at NIS+ and its security aspects.Also in Pete's Wicked World this month: the bug-of-the-month-club has an embarrassing number of new members. Check out the call for volunteers, the mailbox, and information on an upcoming conference. (2,500 words)
 Mail this article to a friend |
Why should you be interested in NIS+? Are you happy with your current distributed naming system? Chances are, unless you're using a commercial distributed naming service, you're using NIS or making due by pushing files like password, shadow, group, and auto_master out to all your systems.
First, consider those two methods. NIS is convenient to use.
Unfortunately, it has very few other qualities. NIS has problems in
large environments, and is very weak where security is concerned. The
other method, using rdist or other methods to distribute
system files, is neither convenient nor secure.
What is the source of these security weaknesses? It all centers around Unix's gullibility. Unix bases network access to resources on hostnames or IP addresses. To allow the root user on one machine to gain access as root to another, the remote host's name is put into the local host's /.rhosts file. Likewise, access by normal users is controlled by hostnames, or hostname/username tuples stored in /etc/hosts.equiv. Users can even set up their own trust relationships by editing ~/.rhosts. (This last feature is enough to give security professionals cold shivers: Any user can extend the security domain of a machine to an arbitrary set of machines.)
All of these mechanisms depend on a hostname defining the machine that is trusted. Unfortunately, hostnames are not trustworthy. Consider that DNS can be fooled into providing the wrong hostname-to-IP-address translation. A hostname in /.rhosts is translated to (the wrong) IP address, a match is made, and the system with that IP address is allowed access to the local host. This same trust is used for NFS mount access. Rather than helping to resolve this problem, NIS exacerbates it.
NIS usually provides system information, including hostname-to-IP-address translation, password, and group file contents to clients on a network. Any machine that can guess the NIS domain name of the server can ask it for this information. Worse, it is very easy for any machine to declare itself as a NIS server and convince other machines to believe its version of the password file. Again, the information NIS provides is used for NFS mounts as well as remote logins. And none of it is trustworthy.
|
|
|
|
|
Along came NIS+. NIS+ was forced on Sun customers when Solaris 2 was released, and it simply wasn't ripe. Commands were confusing, documentation was lacking and incorrect, the code was buggy, and even internally, Sun wasn't using NIS+. Sun's poor release strategy for NIS+ left customers with a bad taste in their mouths, and most are still spitting. The use of NIS+ is still not widespread, although its quality, utility, and value have increased.
NIS+ makes some strong claims. It's supposed to be hierarchical, allowing divisions within a company to control their own namespace while sharing NIS+ information between them. It's also supposed to be more reliable and secure than NIS or even /etc file information. Because this is a security column, we'll just look at the security aspects of NIS+.
But before we can delve into the security, we need to agree on some terminology. Information is stored in NIS+ with a domain. A domain has a name (such as "company.com"), and holds at least two directories (named "org_dir" and "groups_dir"). Each directory contains group objects or table objects. A group object is simply a group name and a list of members (much like a line in the /etc/group file). (see Figure 1).
Figure 1: a NIS+ domain
A table holds a set of related information (like /etc/passwd, /etc/hosts, and /etc/services). Each table has rows (or entries) and columns of information (see the table below).
| User name | Password | UID | GroupID | GCOS | Home Directory | Login Shell |
NIS+ implements powerful authorization and authentication methods. Now that we're speaking the same language, we can explore how NIS+ increases security over the use of /etc files, DNS, and NIS. First, let's consider authorization. NIS+ provides access rights, and owner and group attributes to tables, and to entries and columns within each table. Compare this to NIS, where root may edit any system file and generate a NIS map. Root may make any modifications to this map and all users in all systems in the NIS domain may read all the contents of the maps.
Operations on NIS+ objects fall into the four categories of read, modify, create, and destroy, just as operations on Unix files include read, write, and execute. Similarly, access rights to an object consist of bits to represent the four operations. The final piece to the authorization puzzle is to whom these access rights apply. Unix files have owner, group, and other categories, while NIS+ has nobody, owner, group, and world categories. The difference between nobody and world will become clear when we look at authentication.
Whereas ls reports access using three-bit fields
piper% ls -l /etc/group -rw-r--r-- 1 root sys 306 Jul 23 16:13 /etc/group
NIS+ shows four bit fields:
piper% nisls -l org_dir D r---rmcdr---r--- rootmaster.company.com. aug 20 org_dir
When NIS+ is trying to determine if a principle (a user or a workstation) has access to an object, it first looks at the table access rights. If the rights allow the access at the table level, NIS+ then looks at the specific entry and column. These may have their own rights, or if they have not been explicitly set, they default to the table's rights. If the entry or column has rights set and they allow access, NIS+ executes the operation on the object. If the rights of the table object deny the operation, NIS+ returns an error, even if the individual entry and column rights would have allowed the operation. In political terms, federal rights are superior to state or individual rights.
The level of control afforded by NIS+ over access is extraordinary. There is fine control over who can access each table entry and column. NIS+ also controls the exact operations the principal can execute on that entity: read, modify, create, and destroy. Unfortunately, power has its price, and in the case of NIS+, this price is steep. NIS+ is difficult to learn and use, with more than 20 commands and its own terminology. Next month's column will conclude the overview of NIS+ security, and then you can decide whether this is a price that is worth paying in your environment.
Bug of the Month Club
An unfriendly site on the net, wood.com, has been launching probes
against Web servers in an attempt to exploit a known bug in the
phf program. Discussion of this attack (too much?) is in
the Best-of-security mailing list. The probe is recorded in the web
server log files as
sentry.wood.com - - [15/Jul/1996:09:01:30 -0400] "GET /cgi-bin/phf?Qalias=foo%0aid" 404 -
To find out more about the phf bug, check out
Problems
with Specific Servers, part of The World Wide Web Security FAQ
maintained by Lincoln Stein at MIT.
Unfortunately, security holes seem to be coming with more frequency
rather than less. Solaris in particular suffers from a bug in
vold that can enable arbitrary users to overwrite
arbitrary files on the system. This bug affects Solaris 2.5, 2.4, and
possibly earlier releases. The bug is caused by insecure handling of
temporary files. The solution is to modify the rmmount
configuration file to disable use of temporary files. Unfortunately,
the filemgr will no longer wake up when a new CD is
inserted in the drive. Dang. More details on this exploit are
available from AUSCert, by way of
CIAC.
Joining vold on the programma-non-grata list is
admintool. admintool creates temporary files
and does so insecurely. Seems like we've heard that one before...
There is currently no known patch. Rather, AusCERT suggests that you
chmod 400 admintool to prevent it from falling into the
hands of users.
More information on this bug is available from
CERT.
A bug affecting Solaris, as well as other operating systems, involves
framemaker, the word-processing package. The
floating-license version of framemaker uses a setuid
program named fm_fls. This program writes a file into
/tmp. If that file is then overwritten by a user with a
symbolic link pointing to any system file, fm_fls can be
tricked into, you guessed it, changing the permissions on the target
file. Is it time to give up on the use of /tmp yet?
Details of this bug are available from CERT.
Finally, this month CERT has reported that an old
problem with expreserve
is being exploited on systems that have yet to be patched.
expreserve is the program that preserves the state of a
file being edited by vi or ex.
Unfortunately, it also allows any user of the system that is running
expreserve to become root.
Of course the most titillating news concerning recent break-ins involves the U.S. Justice Department. It suffered from the embarrassment of having its home page vandalized by hackers with a dislike for government and a penchant for scantily-clad ladies. Whether or not the Justice Department's Web server was protected by a firewall, this break-in should serve as a wake-up call to companies that develop and host Web sites. Protect your Web site or prepare to be roasted. (See the Resources section at the end of this column for information on how to defend your Web server.)
Volunteers needed...
It's obvious that a large component of the security picture is being
ignored. CERT provides some information on break-ins, but only after a
solution to the cause of the break-in has been found. And full
information about how the break-in was found is as rare as a secure
Web server. So, you can help me redress this issue. Send me your horror
stories about break-ins. Was it an inside or outside job? What
facility or hole did they abuse? How were they detected? Where they
caught, and what was done if so? I'll print the best stories, with or
without attribution, at the submitter's discretion. Help your fellow
security professionals avoid mistakes and learn from your experiences.
The mailbox
In response to last month's column, one reader asked: "So what does an
ACL do that a group can't? Why would I use it?"
The Unix permission system works fairly well for small environments. It's in larger environments that it begins to break. Most experienced system administrators have run up against the limitations of Unix permissions. For example, consider two users that want to collaborate. Normally, the system administrator would need to create a new group, put the users in it, and have the users set permissions appropriately for file sharing. But Solaris limits to 16 the number of groups to which a user can belong. Some Unix versions are even more restricted, allowing only eight groups per user.
The other problem with this scenario is that the system administrator is involved. With ACLs, no intervention is needed. The user's can add each other to the access list for the files that they need to share.
Another area in which ACLs excel is their flexibility. A given user could have 50 files, each of which is readable, writeable, or executable to a different set of users. For any given file, two users may be allowed to read a file while three others are allowed to write it. This type of fine-grain control is impossible with standard Unix permission functionality.
Hanan Herzog sent along a simple example of ACL status checking. His code sample and comments are available in the sidebar Finding ACL files.
On another topic, upon reading my review of SeOS, Network Information Technology (NIT) got in touch to say it offers a similar product with a different approach. My quick appraisal reveals that, where SeOS modifies system calls to control all access to the system, NIT's products are at the application level. For instance, NIT sells a tool called RAC that controls root access by providing a shell that implements logging, file access control, command restrictions, and so on. I plan on writing a review and technology comparison in a later article. In the mean time, you might explore NIT's home page.
Conferences
November is a good time to get out of the office. Coincidentally,
there's a potent security conference in Washington, D.C. that month.
Hmmm... The conference is Network Security '96, from November 4th to
8th. It headlines Steven Bellovin, and features the top names in Unix
Network Security, including Matt Bishop, Michele Crabb, and a host of
others. I'll be there, participating in workshops on Internet security
tools and security in heterogeneous networks. Looks like a good time.
For more information you can e-mail
sans@clark.net.
Hope to see you there.
Next month we'll finish the coverage of NIS+ security.
|
|
Resources
vold vulnerabilityadmintool vulnerability
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright96.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-09-1996/swol-09-security.html
Last modified:
From Hanan Herzog (hanan@stanford.edu).
Here's a utility that can be used in conjunction with 'find' and scripts in general to determine whether an ACL has been explicitly set for a file. One might want to modify the string outputs to be something more useful than they currently are.
/*
Usage:
a.out [-s] filename
a.out called with only a filename will produce one of the following
output strings: "true" : ACL has been set for filename. "false": ACL has
not been set for filename. "error": ACL status could not be determined
for filename.
If -s flag is provided, there will be no output.
Exit status can be inspected:
0 : ACL has been set for file.
1 : ACL has not been set for file.
3 : Invalid usage error
4 : File not accessible (ACL status could not be checked).
(C) 1996 Hanan Herzog / Stanford University
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/acl.h>
int
usage (char *s)
{
fprintf (stderr, "usage: %s [-s] filename\n", s);
exit (3);
}
int
main (int argc, char **argv)
{
int c, res;
int silent = 0;
char *filename;
while ((c = getopt (argc, argv, "s")) != EOF)
{
switch (c)
{
case 's':
silent = 1;
break;
case '?':
usage (argv[0]);
break;
}
}
if (optind)
filename = argv[optind];
else
{
fprintf (stderr, "one filename argument required.\n");
usage (argv[0]);
}
if ((res = acl (filename, GETACLCNT, 0, NULL)) < 0)
{
if (!silent)
printf ("error\n");
exit (4); /* file probably doesn't exist or is not */
/* accessible. */
}
else
{
if (res > 4)
{
if (!silent)
printf ("true\n");
exit (0); /* ACL has been set for filename. */
}
else
{
if (!silent)
printf ("false\n");
exit (1); /* ACL has not been set for filename. */
}
}
}
About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a Systems Integrator and VAR. He is also Adjunct System Planner for the Computer Science Department at Brown University, a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook.
Reach Peter at peter.galvin@sunworld.com.