Allowing DAC to override MAC in a secure system can occur easily. Yes, the 2 AC policies are "additional" policies in the POSIX 1e terminology, and the kernel checks both DAC and MAC upon system object access. I don't disagree there. But where I disagree is that protecting MAC DBs with MAC is all the protection you need. Where do you store the MAC DB? It's typically in the filesystem. Even where you apply a MAC label to a MAC DB, you still run into problem. If the MAC DB is in /mac/policy/db, and assuming /mac on downward is labeled with a special MAC label, all you need to do is get access to /, which on all systems I've seen is at something akin to "syslo". DAC access to / allows you to move away the offending /mac dir and substitute it with your own. If the system checks both "/" and "/mac" and disallows the operation, there's /dev/sd0 or perhaps /etc/init or /etc/passwd. That is, not all system DBs are MAC protected, and through many of them, you can compromise the system and build up access in order to subvert the entire system. --steve -----Original Message----- From: richard offer To: linux-security-moduleat_private Sent: 7/13/01 12:34 PM Subject: RE: Security through Permissiveness: A Zen Riddle? * frm steven_kramerat_private "07/13/01 07:39:35 -0700" | sed '1,$s/^/* /' * * Second, not all the capabilities in the kernel will allow one to obtain * other * capabilities. Certainly overriding DAC will let someone easily override * MAC (e.g., altering the MAC DBs), but some of the other capabilities at * best allow the user to create DoS scenarios. Allowing DAC to override MAC would be contary to the point of MAC. In any sensible MAC system, the MAC checks would be performed before the DAC ones. System DBs would be protected by MAC as well as DAC. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Jul 16 2001 - 08:32:31 PDT