On Tue, 9 May 2000, Chris Evans wrote:
> 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.
Of course.
> 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?
ISTR NT has at least one such hole - I have seen at least one "kernelkit",
where you just call a code fragment, and it returns to you in kernel
mode. No doubt something similar could be constructed for Linux, given
enough time... (Having said that, Linux on the ARM-26 would be pretty
tough. When you return from the kernel, the CPU flags are restored along
with the program counter, since they are both stored in R14. Tampering
with the registers in kernel mode from userland should be a lot harder
than tampering with the stack, I suspect.)
> 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.
No. ATM, we have BOTH problems; with MAC, we [almost] eliminate one of
them. MAC shouldn't introduce any NEW problems, even if it isn't a perfect
solution to the existing ones.
> 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....
NT getting a certification pretty much rules out the possibility of taking
the criteria seriously...
James.
-
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