Welcome, and also POSIX.1e auditing (fwd)

[Casey Schaufler]

Allow me a brief introduction. My name is Casey Schaufler, and I
was the final technical editor for the POSIX P1003.1e/2c (aka P1003.6)
effort. I was active from the project's inception with /usr/group
in 1987, and carried over into POSIX in 1988. While I took time off
from attending meetings, members of my group continued to contribute
until I rejoined. I was technical editor for Drafts 15 and 16, and
was working on Draft 17 when the project was finally disbanded.
I have designed and implemented, not all alone of course, the
Capability, ACL, and MAC features in Irix. I will do my best to
pass along any wisdom I may have acquired in the process. BTW,
I know that I don't spell worth a 286. 

Robert Watson wrote:

> 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 personal opinions, in brief:

ACLs:

Implement the acl_[gs]et_file() system calls. Ignore the
ponderous ACL manipulation functions, favoring acl_{to,from}_text()
instead. Let's be honest, there are very few programs that really
care about ACL manipulation. Pass on the directory default ACLs, too.

Audit:

The audit section is a disaster. The two major camps fought so hard
that in the end no one survived, and the spec shows it. There are
a few good ideas present, but the section lacks any sort of
usefullness.

Capabilities:

The capability (formerly privilege) mechanism works reasonably well.
The inheritance mechanism is a might hard to deal with in practice,
but I'm reasonably certain that there isn't a simpler alternative
that will actually work for both applications written with capabilities
in mind and those which rely on the traditional mechanisms.

Information Labels:

Ignore these completely.

Mandatory Access Control:

Very workable specifications. It would be nice had there been a
concensus on dealing with the /dev/null and /tmp problems, but
there are many schemes available to choose from and in the end it
doesn't really matter which you use.

> In my mind, there are a few main issues:
> 
> 1) Draft inconsistencies

Lots and lots. We spent the last two years on the project dealing
with virtually nothing else. Many of these resulted from the change
of terms from privilege to capability. Some came from differences
in mindset between the SVR4ES, SecureWare, and other camps, and
their levels of involement at any particular meeting.

> 2) Draft ambiguities and vague areas

Usually the result of a vendor screaming "But that would proclude
a reasonable implementation (mine!)" whenever a definitive statement
was made. The audit section is by far the worst in this regard,
with the probable cause being that no one had actually implemented
it.

> 3) Draft feature deficiencies

Usually the result of compromise. In audit, a result of the fact
that no one had actully tried to make it work.

> Similarly, in the capabilities draft, the specified capabilities are not
> very useful.

I disagree with this assertion. The Trusted Irix product runs
without a superuser using these capabilities and a few more which
are outside the scope of POSIX. The capabilities defined are there
to address specific restictions (appropriate privilege statements)
in P1003.1 and can't say anything about sockets (for example) which
are not in .1.

> Another lack of a feature is a standard flattened file format
> for audit records.

Yup. The one proposal presented which could have addressed this
included a truely reprehensible API. Rather than keep the good bits
and chuck the bad, the whole thing was rejected and any attempts to
bring back the good was squashed because of the ABI. 

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

It failed in this regard, especially for audit.

> 4) Portability and Testing

> having access to one-another's test
> suites would be a great boon.

I agree.

> Also, for reference, here is the contact information listed for Casey
> Schaufler, the technical editor, in the draft: ...
> I do not know how accurate this currently is, especially given the recent
> changes at SGI.

Rumors of SGI's demise are greatly exaggerated.

-- 

Casey Schaufler                         voice: (650) 933-1634
casey at sgi.com                           fax:   (650) 933-0513
schaufler at dockmaster2.ncsc.mil
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message