> 1) You could have the activity of the daemons and other processes
> audited in case of a problem. This could be very useful when trying
> to track a problem or security hole.
This is a feature of C2.
> 2) The object reuse requirements would make it less likely that a
> daemon or other process could be tricked into sending info from a
> previous network request.
This is a feature of C1.
> 3) The TCB protections will make it less likely that bugs and holes
> in programs can circumvent or damage the system operation.
This is a feature of C1.
> 4) Daemons could be run in a mode that doesn't have access to any
> file or other resource on the system (e.g., on UNIX, run a daemon
> as user "noroot").
C2 does not require such a mode exist.
> C2 (and all other trusted systems) provides security enhancements
> in ways that are useful even when no user is on the system.
To be precise, systems require certain security concerns be met to
satisfy C2. These concerns, however, are so weak that apart from
the auditing requirements just about *any* operating system that
has any meaningful security model satisfies C2.
Stock bog standard UNIX satisfies C1, and the only requirement it
misses under C2 is auditing. Most of the enhancements people add for
C2 UNIX systems are not C2 requirements at all. Particularly, there
is no C2 requirement for either access control lists or modifying the
standard password file (shadowing passwords are a good idea, but C2
doesn't say anything about them).
References:
|
|
