Controlling ACLs
Down and dirty with the new access control list facility in Solaris 2.5
August 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}
|
|
Controlling ACLsDown and dirty with the new access control list facility in Solaris 2.5 |
August 1996
|
There's a new security facility in town -- ACLs -- and it's built into Solaris 2.5. Access control lists allow for fine-grained control of which users and groups can access a given file or directory. The good news is that using this facility requires learning only two new commands. The bad news is that the command syntax could be more appealing.Also in Pete's Wicked World this month: a serious hole in
rdistin the bug-of-the-month-club. In the bookstore, an interesting white paper on the performance of the secure shell (ssh) (2,300 words)
 Mail this article to a friend |
Remember Apollo computers? They ran a very nice operating system called Aegis. Aegis supported ACLs. When Apollo decided to merge Unix functionality into the system, Unix's file-permission-bit model was incorporated into Aegis, and never again could you determine the exact access allowed to a file. And never again could you set permissions so files had exactly the accessibility you wanted. And then Hewlett-Packard bought Apollo and Aegis disappeared.
So it was with trepidation that I explored the new ACL feature in Solaris. Would setting and understanding permissions become a journey into darkest Africa? I'm glad to report that I made the journey and returned, none the worse for wear. The Sun ACL facility, under the right circumstances, is a powerful and useful addition to your security arsenal.
The Sun ACL facility is compliant with the POSIX 1003.6 specification. Over time, other vendors will adopt this standard, and ACLs will be interoperable between platforms. Sun's implementation works with the User File System (UFS) as well as with NFS version 2 and 3. Unfortunately, ACLs are implemented out-of-band -- Sun could not change the NFS implementation (and vary from the standard) so it implemented a separate client/server protocol to communicate ACL information across a network.
The ACL facility allows you to define more than just the usual eight permission bits for a file or directory. You can define a list of users (based on user-id or name) and groups (again, number or name) that you want to have access to a file. For each user or group getting special access, you can define read, write, or execute access permission.
There are only two commands that you need to learn for Solaris ACLs.
They are setfacl for setting a file's ACLs and
getfacl for reading them. There are also a bunch of
system and library calls that make the ACL facility available to
programs. One confusing aspect of ACLs is that, in essence, every file
already has an ACL entry. Running getfacl on a normal
file reveals some ACL information:
spock% cd /usr/tmp spock% touch foo spock% ls -l foo -rw-r--r-- 1 pbg staff 0 Jul 22 13:35 foo spock% getfacl foo # file: foo # owner: pbg # group: staff user::rw- group::r-- #effective:r-- mask:rwx other:r--
This ACL information is merely getfacl's interpretation
of the Unix permissions on the file. The user, group and
other information is a straightforward display of the
permission bits for those fields. The mask field is very
similar to the Unix umask method. It defines the maximum
permissions allowed for users (other than the owner) and groups. Even
if a user or group has permissions set that exceed the mask, the mask
limits their access. The #effective display shows, for
each user (except the owner) and group, the effect that the mask has
on the permissions. The #effective output is the one to
look at to determine exactly who can access the file and exactly what
they are allowed to do.
To set an ACL for a file, use the command setfacl:
spock% setfacl -m user:jeff:rw- foo spock% ls -l foo -rw-r--r--+ 1 pbg staff 0 Jul 22 13:52 foo spock% getfacl foo # file: foo # owner: pbg # group: staff user::rw- user:jeff:rw- #effective:r-- group::r-- #effective:r-- mask:r-- other:r--
The -m option tells setfacl that I want to
modify the ACLs for the file. Use the -s option to set
the entire mode, but then you must type in the user, group, and other
access bits as well:
spock% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jeff:rw- foo
To set general user, group, and other permissions, use the
field::perms identifier. To set ACLs for individual users
and groups, use the field:uid or gid:perms
identifier.
But back to our previous example. Notice that the effective access for user Jeff is unchanged, he can still only read the file, not write to it. That's the result of the mask being applied to his permissions. To grant Jeff the access desired, I need to:
spock% setfacl -m mask:rw- foo spock% getfacl foo # file: foo # owner: pbg # group: staff user::rw- user:jeff:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:r--
Now Jeff has read and write permissions to the file, while all others
have only read access. Of note is the slight change in behavior of the
ls command. Any file with specific ACL information is
shown with a + at the end of the permission field. Unfortunately,
find doesn't seem to have an option to find all files
with ACL lists.
By now, your warning bells are probably going off. (No, it's not the
ice cream truck...sit back down.) A hacker, having broken into your
system, could use the ACL facility to create back doors. These back
doors are very difficult to spot -- only inspection of ls
output will identify the target files. Fortunately, the programming
interface to Solaris ACLs allows the creation of utilities to search
for files with access control lists. (If you write such a program,
please send it to me and I'll make it available in a later column.)
Using the ACL facility on a directory adds some new twists. As well as
setting an ACL for the directory, you can set a default ACL for the
directory. This default ACL is used to set the ACL on every file
created within the directory. The only way I managed to get directory
ACLs to work was using the -s option with a very-long
parameter string:
spock% setfacl -s user::rwx,group::rw-,mask:r--,other:rw-,default:user::rw-,\ default:group::r-x,default:mask:rwx,default:other:r-x bar spock% ls -ld bar drwxr--rw-+ 2 pbg staff 512 Jul 22 14:11 bar spock% getfacl bar # file: bar # owner: pbg # group: staff user::rwx group::rw- #effective:r-- mask:r-- other:rw- default:user::rw- default:group::r-x default:mask:rwx default:other:r-x
Now set a default ACL, and create a file in the directory:
spock% setfacl -m default:user:jeff:rwx bar spock% getfacl bar # file: bar # owner: pbg # group: staff user::rwx group::rw- #effective:r-- mask:r-- other:rw- default:user::rw- default:user:jeff:rwx default:group::r-x default:mask:rwx default:other:r-x default:user::rw- default:user:jeff:rwx default:group::r-x default:mask:rwx default:other:r-x spock% touch bar/test spock% getfacl bar/test # file: bar/test # owner: pbg # group: staff user::rw- user:jeff:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:r--
There are several other aspects of ACLs, including deleting ACLs and using abbreviations and permission bit numbers (rather than symbols). This information is provided on the appropriate manual pages.
There are also several gotchas to watch for. To use ACLs over an NFS mount, both the client and server must be running Solaris 2.5 or better. If the client is running 2.5 but the server is running 2.4 or lower, you'll see an error such as:
spock% touch foo spock% getfacl foo # file: foo # owner: pbg # group: staff user::rw- group::r-- #effective:r-- mask:rwx other:r-- spock% setfacl -m user:jeff:rw- foo foo: failed to set acl entries setacl error: Operation not applicable
You'll get a similar error if you try to use ACLs in a swapfs-based
directory (such as /tmp). Finally, there's a
"non-feature" of ACLs when used with tar.
tar itself works well with files that have associated
ACLs. Unfortunately, the tar file is not readable under previous SunOS
and Solaris operating systems.
It is also important to note that ACLs "stick" to a file during copy
and rename operations. To remove the ACL from a file use setfacl
-d for each entry. When the last entry is removed, the "+"
disappears from the file's ls display.
You should probably get to know the ACL facility, including how to use it, how to determine the ACLs on a file, and how to detect files with ACLs. It's a useful facility that integrates well with the Unix permissions you know and have come to understand. Besides, the hackers are probably playing with it already.
|
|
|
|
|
Bug of the Month Club
The Eight Little Green Men have been at it again. They report that
rdist on SunOS 4.1.x and Solaris 2.x has a bug that
allows a local user to obtain root permissions. A description of the
bug, and an exploit script for SunOS, is available at their
web site.
As interesting as the bug itself is, the cause of the bug and the
method used to find it are instructive as well. The bug is caused by a
call to sprintf. In this instance (and probably many
others in Unix utilities), the sprintf is used to write a
string to a malloced memory space (on the program's
stack). The sprintf does not check for the string length
that it is writing, so it could overwrite the stack and write into the
code space, enabling execution of arbitrary programs. The
sprintf in question echo's the user's input as part of an
error message, so user input is written to the stack. By sending a
special input (and causing the stack to overwrite the code section),
the user can cause rdist to execute a program he or she
designates.
Normally, programs run with the same privileges as the user who
invoked them, so the ability to cause a program to invoke some other
arbitrary program gains nothing. However, with a set-UID program, the
process runs as the UID indicated in its permissions. In the
rdist case, rdist is set-uid root, so the
arbitrary program is invoked as root and the system is broken.
A debugging tool called "libC/Inside Shared Library Tracing" was used
to monitor the execution of rdist and watch for a
malloc followed by an unlimited sprintf
sequence in which the sprintf echos input from the user.
This sequence is dangerous, and should be eradicated by computer
companies from their code. All software vendors (as well as in-house
software developers) should be aware of this and eliminate this code
sequence from any set-UID or set-GID programs that they write.
On the
best-of-security mailing list,
there was mention of a continuing bug in mailx that
allows the use of a race condition to gain root permission. However,
this bug does not appear to be present on Solaris machines, so at this
point it can be assumed to be a false alarm. While you're checking out
best-of-security, be sure to read the spoof on CERT advisories by Nick
Kralevich. I think he just ruined the movie "Independence Day" for me
though.
The bookstore
It's always nice to find two interesting topics combined in one paper.
In this case, the topic is SSH (see
"The SeOS security blanket",
June 1996 SunWorld), the
secure shell. The question is, how much of a performance penalty do
you pay if you're using encrypted communications? The answer is
provided in a
paper by
Bradley Kuszmaul at Yale University. In summary, the author shows
that in his tests, encrypted communications have about 70 percent of the
throughput of unencrypted data. A reasonable price to pay for private
communication.
Sun has produced an informative white paper about Solaris security features and products. The white paper covers Sun's four-layer model of security, has information on Sun and third-party security products, and drops hints about the forthcoming GSS-API and PAM standard implementation.
GSS-API is a new authentication-method integration standard, based on
RFC-1508.
Once vendors implement GSS-API, uses will be able to plug current and
new authentication methods of their choice into their systems. No more
playing with library file replacements or installing new version of
login. PAM is complimentary to GSS-API. GSS-API defines
network-based client/server authentication interfaces and PAM defines
local authentication interfaces. Just think of PAM as the
nsswitch.conf file for authentication. (These topics will
be covered in future editions of SunWorld.)
The mailbox
It is now clear to me that if I'm ever feeling lonely, all I need do
is make disparaging comments about Linux and my mailbox will soon
overflow. I received several messages commenting on my coverage of a
Linux bug in last month's column. Almost all of the messages
complained that I unfairly singled out Linux. Perhaps so, but I've
singled out other operating systems in the past (including Windows/NT
and Solaris). Coverage of Linux is just par for the course. (See
SunWorld Online's
letters page.)
The letters did bring up a valid point, however. Always consider your security as a chain, and look for the weak links. It does little good to strongly secure your Solaris machines and to ignore other machines on your networks. A break-in occurring on any one of them can compromise the security of every machine on that LAN. Just consider what information a packet sniffer could capture on any of your networks. So be sure to consider the security of all the machines that live on your networks (whether you manage them or not). Follow good security procedures by keeping the systems up-to-date with the latest operating system releases and patches, and increase security in the many ways detailed in this column and elsewhere.
I won't mention a couple of new Linux root vulnerabilities reported by CERT and others last month...
Mistakes were made
Apologies to Douglas Stewart, author of a letter quoted here last
month, for misspelling his last name. Just call me Peter
Glavin.
Next Month, on "As Pete's Wicked World Turns"
Next month we'll start delving into the great morass known as NIS+.
But fear not -- treading the right path can get you to the other side
with nary a hair out of place.
|
|
Resources
rdist vulnerability
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.
|
|
|
|
![[(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-08-1996/swol-08-security.html
Last modified: