Jesse Pollard wrote:
> Nope. The problems:
> 1. inadvertant granting of capabilities because a user gets added to a group.
> 2. No positive identification and "least privilege" implementation. Just
> because a GID is given a capability is no reason to give that capability
> to all members of the group.
> 3. Group access is a descretionary control. Capability lists are a mandatory
> control. Don't mix the two.
The SystemV/MLS product from AT&T Federal (circa 1986) co-opted
the group bits as the index into a table which included a variety
of security attributes. Their experiance influenced the POSIX work.
No one else ever did such a thing as a result of their experiance.
> They are difficult to follow, but they are based on expierience in trusted
> system administration. They work to prevent accidental security exposures,
> prevent security "leaks" of more privileged/sensitive data to less security
> processes. Systems are used every day that support most (all?) of the
> specs in that document. See the growing proliferation of "Trusted XX" operating
> systems. All of these are implementing either most of or a superset of the
> specifications containd in the "withdrawn" standard.
It's true!
>
> > Since POSIX tends to document standard practice - when standard
> >practice leads to security, administrability, and maintainability -
> >I think that - on this one issue - we should lead the way.
The 1003.1e/2c group came into the effort without a clue of what
to do. If the document resembles a camel, well that's why. No one
had an implementation at the begining. We designed our own and each
others systems together.
>
> IMHO, that is partly why I think it was withdrawn. The timing of the
> withdrawal appeared to be shortly before and during the debate over the new
> "Common Criteria" (CC) for security specifications. The POSIX committe (I think)
> decided to wait for acceptance of CC to become practice.
Well, actually, no, that had nothing to do with it. We broke up due
to lack of corporate sponsorship. POSIX as a whole had lost favor,
trusted systems hadn't recovered from the "C2 in '92" collapse,
and I DIDN'T WANT TO GO TO POUGHKEEPSIE ANY MORE!
> > as the work of $DIETY.
As flattering as the description might be, We recognize Our falability.
Especially when it comes to spelling.
--Casey Schaufler Manager, Trust Technology, SGI casey@sgi.com voice: (650) 933-1634
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:14 EST