Summary about Posix.1e

[Download] [Mailinglist] [Scope] [Status] [Implementations] [Related links] [Credits]

Existing POSIX security functionality is inadequate for an increasing number of situations and applications. There must be certain minimal functionality and interfaces built into POSIX so that security mechanisms can be implemented without adversely affecting applications portability.[from an anonymous source]

Posix.1e is a standards paper describing security extensions to Posix and surely better than nothing when it comes to security. Many security experts have put work into it over many years and so it's ideas should at least be considered. For example, one such idea is to bind privileges to processes instead of UIDs. That allows you to start daemons like named under a different UID than root.

Recent messages on bugtraq like "Unix kernel changes" indicate that people partly try to re-invent the wheel of Posix.1e: which changes could be done to a Unix kernel to achieve a more secure system? One thing is clear: such changes ("extensions") must be standarized in order to allow portability. Only if features are identical accross many platforms, developers will widely use them in their software. That is the goal of Posix.

Of course, new tools are no substitute for fixing broken software, as broken software is often still on a domain boundary to restrict access to files, etc. However, from the statistical point of view, there is always a certain percentage of broken software on a system. You simply don't know it yet. If the security extensions for Posix provide you with some mechanisms, which limit the damage until you fix a security hole, it is a clear advantage. And granting privileges to applications for which you don't have the sources, comes into mind, too.

Mailinglist for discussion about Posix.1e

We think cooperation and discussion between implementors on different platforms can only benefit the goal of portability that POSIX represents -- we encourage those involved, or interested in being involved, to subscribe to the mailing list Robert Watson has set up for this purpose. The address for subscriptions ist posix1e-request@cyrus.watson.org.

He writes: "An archive of this list is available as a shared IMAP folder at {cyrus.watson.org}lists.sec.posix1e and can be accessed by providing anonymous as the username, and your email address as the password. If an alternative mechanism for accessing the archive is desired, such as a web page, that can probably be arranged."

"I discovered a number of inconsistencies in the Audit component of the specification; making sure we all resolve these types of problems in the same way is important. As extensions are added to fill some of the gaps in .1e functionality, keeping those consistent across platforms would also be useful. Similarly, as test suites are developed for components, sharing these test suites helps all implementors. As applications become available that know how to make use of POSIX.1e, this forum might be a useful place to continue discussion of issues relevant to the task."

Another goal of the mailinglist is to come around the lack of publically downloadable documentation (see below).

Scope of Posix.1e

This is the definition of Posix.1e taken from the standards paper:

: Abstract: IEEE Std 1003.1e is part of the POSIX series of standards. It defines security interfaces to open systems for access control lists, audit, separation of privilege (capabilities), mandatory access control, and information label mechanisms. This standard is stated in terms of its C binding.

The work is heavily influenced by US DoD Orange Book terminology and thinking. The official terms are "IEEE 1003.1e" or "Posix.1e". Older terms (which one should avoid) are "P1003.1e" and "Posix.6".

About the related standard Posix.2c taken from the standards paper:

: Abstract: IEEE Std 1003.2c is an amendment to IEEE Std 1003.2-1992. It defines security utilities to open systems for access control lists, separation of privilege (capabilities), mandatory access control, and information label mechanisms.

Status of Posix.1e

After 13 years of work on Posix.1e, the IEEE/PASC/SEC working group approved the following resolution at its January 15, 1998 meeting:

: PASC/SEC hereby withdraws sponsorship of the following PARs:
P1003.1e (Security APIs)
P1003.2c (Security Command and Utilities)

So the Standard Posix.1e is not likely to be "finished" or "released" anytime soon. However, the recent message about "IRIX 6.5 Security Features" indicates that the ideas behind Posix.1e are still of interest for some vendors. Maybe it's a chance for us to step in and finish what is left off.

Implementations

This section describes which operating systems implement what parts of Posix.1e/2c.

FreeBSD: Information about the FreeBSD POSIX.1e implementation
Linux: Process capabilities are implemented and the C-library is available from ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
Solaris: Several people reported, that Solaris ACLs are almost identical to POSIX.1e ACLs.

Credits

My special thanks go to the following people for their contributions:

Robert Watson <robert!cyrus.watson.org>
Andrew Morgan <morgan!transmeta.com>
Aleph One <aleph1!UNDERGROUND.ORG>