Chris Evans <chris@ferret.lmh.ox.ac.uk>:
>
> 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.
>
> Linda,
>
> 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
> (tm).
>
> 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.
Actually the previous was all-powerfullness of the root user AND the all
powerfulness of the monolithic kernel.
At least the new one is down one problem.
> 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...
These certifications are not true certifications, but management directive
that "it is sufficiently secure...". It's that kind of "certification" that
allows windows to be used in critical operations (and where something so
trivial as a divide by zero can cause catastrophic failures...)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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 : Mon May 15 2000 - 21:00:14 EST