On Tue, 9 May 2000, Linda Walsh wrote:
> As for interaction, both are checked, first MAC, then Discretionary
> Access Control (DAC) (UID/GID). DAC is call discretionary because it
> is at the user's discretion, whereas MAC is not. Files a user creates
> are only at their current sens/int level. W/o special privileges, they
> can't change those levels.
One thing to be careful of when you implement MAC. Remember that the
kernel is fully trusted. A single flaw in the kernel and bang, a user can
circumvent any MAC.
The kernel API is very non-trivial, and represents a lot of code. How sure
are you that there isn't a subtle signed/unsigned issue somewhere on the
kernel API which leads to a kernel mode buffer overflow?
I think the principles behind MAC are very cool. However, in "real
world" security situations (as opposed to feature list based security), a
monolithic kernel is Not What A High Security System Should Be Based On
With MAC (and capabilities), we'd lose one big problem with UNIX security
and gain another.
The previous problem? The all-powerfulness of the root user. The new
problem? The all-powerfulness of the monolithic kernel.
Amusingly, though, such practical considerations typically aren't a
barrier to high security certification. This is one of the reasons I view
a lot of certifications as of limited value. However, since Governments
see things differently....
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:13 EST