Welcome, and also POSIX.1e auditing

[Robert Watson]

First, I'd like to thank Winfried for his post to bugtraq; I think his web
page summarizes the concerns with POSIX.1e quite well, and I suggest that
those interested take a look at it.

Second, I am keeping an archive of this list in a shared IMAP folder at
{cyrus.watson.org}lists.sec.posix1e.  If an alternative format is
preferred, that can probably be arranged.

I'd like to start some discussion about the role of POSIX.1e in the
development of new security features on the various free (and otherwise) 
operating systems out there.  My interest has largely stemmed from work
implementing the POSIX.1e auditing facilities for FreeBSD 4.0.  This work
is almost complete, and before I start making this code widely available,
I thought it was important to discuss the portability and feature
ramifications of POSIX.1e.  My intent is to move on through the POSIX.1e
draft, feature by feature, for FreeBSD (and possibly other platforms :).

In my mind, there are a few main issues: 

1) Draft inconsistencies

The draft is a draft; as such, there are inconsistencies.  For example,
the auditing chapter (which I am currently most familiar with because of
my implementation work) has simple things like constant name
inconsistencies: on some pages, it uses on name for a constant; on others,
other names.  Many of these are fairly straight forward; once I have
finished my auditing implementation, I'll post a list of the
inconsistencies that I found on the way and what I thought the correct
resolution was.

2) Draft ambiguities and vague areas

These in my mind are the more complicated draft problems: situations where
the behavior is sufficiently ambiguous that two different implementers
might choose quite different interpretations.  While (1) can result in
different interpretations, these are fairly straightforward to remedy.
For example, in the auditing draft, pointers to aud_info_t records are
returned.  The draft doesn't state whether these are copies or references
to a central shared copy.  Many places in the draft, when a pointer or
descriptor is returned, it is explicitly stated whether modifications in
the returned objects result in modifications to the shared object.  But
not in that case.

Similarly, the draft does not account for some error conditions that might
result from a number of likely implementations.  Also, it defines some
functions that don't seem to be implementable (aud_read() seems to offer
an atomic record read service: but given that records are multi-part and
variable length, it's not clear how this service can be offered using a
device and non-blocking file descriptors).

3) Draft feature deficiencies

The draft defines many useful things.  But sometimes I found that they
weren't really sufficient for some of the applications I envisioned.  For
example, the aud_copy_int() function accepts a pointer to a binary blob,
and returns an audit record structure.  However, it does not accept a
length field for the binary blob.  As such, it is not appropriate for use
on audit entries from untrusted sources, or for protecting against
corrupted records.  My own implementation accepts an extra size argument
on a variation of the call, and then the aud_copy_int is a wrapper that
tells it to ignore the size limit.

Similarly, in the capabilities draft, the specified capabilities are not
very useful.  Here's an excerpt from any email I sent to Winfried a few
weeks ago:

  I find that the capabilities they define could generally be used to
  leverage root access in a traditional UNIX system.  Here are some of
  them: 
 
  CAP_FOWNER - "in general, this capability, when effective, will permit a
  process to perform all the functions that any file owner would have for
  their files"  -- i.e., could modify the password file, login, etc.
 
  CAP_FSETID - "This capability shall override the following restrictions: 
  that the effective user ID of the calling process shall match the file
  owner when setting the set-user-id (S_ISUID) ... bits on that file" --
  i.e., could make sh setuid root. 
 
  CAP_KILL "This capability shall override the restriction that the real
  or effective user id of a process sending a signal must match the real
  or effective user ID of the receiving process" -- i.e., can manipulate
  processes (such as causing core dumping, dumping of debugging info,
  etc). 
 
  CAP_LINK_DIR "This capability overrides the restriction that a process
  cannot create or delete a hard link to a directory" -- this doesn't make
  sense in most UNIX systems, as what was once a reasonable tradition is
  now a fundamental requirement for some of the graph-based algorithms
  that assume no loops in the file structure.  This would cause nasty
  behavior on a number of UNIX systems. 
 
  CAP_SETFCAP "This capability shall override the restriction that
  aprocess cannot set the file capability state of a file" -- i.e., a
  process can effectively give itself any other capability. 
  
  CAP_SETGID -- "This capability shall override the restriction in
  setgid() function that a process cannot change its real group ID or
  change its effective group id to a value other than its real group id" 
  -- on many systems using GIDs and setgid to protect privileged
  functionality (access to /dev/kmem, log files, mail queues, etc), this
  would yield root access fairly easily.

  CAP_SETUID -- ... user id ... -- same thing, only worse. 

My feeling was that none of these was a really useful division of
appropriate privilege, although the concept is probably a useful one.  The
Linux people seem to have a far more comprehensive set of more limited
capabilities, far more in line with what I had in mind.  However, these
are extensions to the draft, and something I'd like to see be consistent
across the platforms.  I'd like this mailing list to be a place where we
discuss such things, if possible :-).  One possibility would be for us to
maintain a POSIX.1e.extensions document describing resolutions to
ambiguities and useful extensions.

Another lack of a feature is a standard flattened file format for audit
records.  The spec leaves this up to the implementation: however, it seems
to me that such a format might be shared quite easily among
implementations, and would allow for non-source distributed
post-processing applications, such as in intrusion detection systems,
which would work across platforms. 

POSIX.1e promised portability in security extensions, but only if the
draft is sufficiently broad to cover the basic requirements of these
security extensions. 

4) Portability and Testing

Implementing auditing has involved a fair amount of source code; to help
test my code, I've written a small auditing test suite.  While it is far
from comprehensive, it has proven very useful.  I assume that those Linux
folk involved in capabilities and ACLs have written similar code.  As more
platforms implement these services, having access to one-another's test
suites would be a great boon.  Not all features can be tested, but the
standard sets of library calls and manipulation routines would be useful
to have shared tests for.


While there are certainly other issues, these are the main ones that have
been on my mind recently; I welcome any comments of suggestions in
resolving these issues.

Also, for reference, here is the contact information listed for Casey
Schaufler, the technical editor, in the draft:

Casey Schaufler
Silicon Graphics
2011 North Shoreline Blvd.
P.O. Box 7311
Mountain View, CA 94039-7311
(415) 933-1634 (voice)
(415) 962-8404 (fax)
casey at sgi.com
Schaufler at DOCKMASTER.NCSC.MIL       

I do not know how accurate this currently is, especially given the recent
changes at SGI.

  Robert N Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services             http://www.safeport.com/

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message