On 11 Aug 2001, David Wagner wrote: > Crispin Cowan wrote: > >IMHO, this is The Application's Problem. [...] > >[...] An application that wants to be non-brittle should > >inspect error codes coming back from sys_lsm, looking for a return code of > >"EWTF?" ;-) and react appropriately. > > I'm probably being paranoid, but it seems there is little the application > can do to gain confidence that its request won't be misinterpreted. > Who knows, some aspects of the syscall-protocol exported by both modules > may be similar enough that you don't get a EWTF but you do get some > action taken that the app wouldn't have approved of. Actually, there is a whole lot an application can do: 1) issue a "no-brainer" call. If it's refused, give up. 2) just look in /proc/modules ... or anywhere else in /proc/ or a private fs, or even a public one, where the module signals its existance and active status. If the module is primary-only and it is loaded, that's a certain level of assurance (equal to knowing the magic number to pass the interface.) If the module is stacked, it's there... trust the stacking module (you gotta trust somebody, and if it's in the kernel, I've been told, distrust is wasted time.) 3) use any module specific means to determine if the loaded security module is loaded and then decide if it should continue. The number of possible mechanisms approaches infinity. I'm not going to enumerate those that I've considered, since the more unique it is, the better the assurance (at this point.) 4) possibly others... NONE of these necessarily prohibits an application from trying (a la 1), so the module has to be smart enough to check all it's received arguments and verify that the application is making a correct request. PREVENTING, by hard code in the kernel, an application from trying prevents, in a very real way, the module from knowing the application tried something "evil" (or just "wrong") and prevents the module from acting on that information. > > For instance, maybe in SubDomain sys_security(SD_CHANGEHATS, s) means > ``change to subdomain named by s, or, if s==NULL, go back to the original > subdomain'', and maybe in SELinux sys_security(SE_SETUID, u) refers [...] > I don't see what an app can do to reliably avoid this failure mode. I understand this argument, but would suggest 1) a well designed module should be able to prevent its own replacement. 2) a module has many good means (other than a magic number in the syscall) to inform its "complement of applications" of its existance. 3) applications will fail no matter what you do. The Kernel/Module must block it. Any other model is insanity, in Linux. > > The easies solution, IMHO, is not a callback, but rather to be more > explicit in the syscall interface: for the app to pass along with each > syscall a token that uniquely identifies which module's protocol it > expected would be used for interpreting that syscall. I'm not sure > whether this problem is significant enough to justify such a fix, but > it's not hard to fix if it seems troublesome. This is true, and I even believed it was a good compromise... but more recently, I've decided it's an unnecessary compromise. Of course, I'll go back to it if hard evidence is presented that I'm wrong. J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ 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 : Sun Aug 12 2001 - 18:16:04 PDT