> -----Original Message----- > From: Seth Arnold [mailto:sarnoldat_private] > Last, the two reasons I have heard for moving the MAC checks first are > thin by my standards: (a) a POSIX draft says to do MAC first > (b) running > MAC first prevents the DAC decision variables from being > known. I don't > think that we ought to sacrifice speed just for an old POSIX draft. I > also don't think we should be overly concerned with protecting the DAC > decision variables from the user: since the syscall can't return > different error messages based on MAC or DAC error, really only timing > attacks would glean this information; also, it is beginning to smell a > lot like an attempted defense against covert channels. Which, while an > honorable thing to do, starting with Linux may not be the > right approach > for any application that truly requires keeping covert > channels such as > DAC data closed. Why is it that MAC and DAC both must return the same error messages? I can easily envision a MAC policy that returns more errno values than the access errors. Given that it is a possibility to have different MAC and DAC return codes, it becomes an issue of storage channels, not only timing channels. In the past, I would have agreed that covert channels are a bit esoteric to worry about in real-life OSes. But given the propensity of crackers to defeat so many existing protection mechanisms, isn't this something we should consider (at least bookmark it for later examination)? I'm also curious as to why you don't think Linux is an appropriate system for which to eliminate covert channels. --steve kramer _______________________________________________ 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 23 2001 - 06:19:28 PDT