I would rather answer this directly than publicly, but since it was sent publicly to immunix.org (is that the same as wirex?)... On Mon, 1 Oct 2001, Seth Arnold wrote: > On Mon, Oct 01, 2001 at 09:05:19PM -0400, jmjonesat_private wrote: > > I also am very concerned that LSM hasn't given REAL attention to race > > conditions. While I know of mechanisms to moderate this problem, and have > > no doubt my knowledge is severely limitted, I would suggest that "SMP/Race > > tolerant" or better would be a GREAT arguing factor *FOR* LSM. > > I don't think that race conditions have been overlooked when placing > hooks. Generally, if a hook could suffer from race conditions, so could > the kernel code -- and the kernel developers have tried to protect > important structures with locks. My observation, which may be incorrect, is that... because the hooks are deeply placed they are sometimes invoked more than once, and, furthermore, they are sometimes (rarely, but still occasionally) invoked multiple times in myriad ways during a single syscall. Also, because they try to provide raw data and pointers to kernel objects, the same object MAY be invoked more than once during the service of a single application level request. Since the same object/structure can be accessed more than once and, because of the "deep" nature of LSM, it is possible that there are significant periods of time between these accesses (one cycle?). As such, there may be changes to the structures referenced between those accesses. Since there is no mechanism to preserve the "syscall thread", there is no assurance that those structures are unchanged between access. Isn't that the essence of a race condition? I don't know if there are vulnerabilities inherent in the LSM paradigm. I haven't pursued that... since it's a very deep-layered, difficult situation to construct. However, I don't think there's been any serious, deep level consideration of this *slim but apparent* vulnerability. It's just my opinion. I will not apply the resources to trying to prove a vulnerability. I am NOT convinced that it is not possible, at this point, though. What is not excluded by proof, is, essentially, possible. You do have a point, though. Adding SMP support and such to Linux opened that question. I just don't think LSM has discussed or evaluated this in depth to the point that *anybody* can say that LSM has improved the situation, or, even, not made it worse. > > Mostly, the evidence of care about races doesn't show up in the patches, > but that the headers list which locks are held in which hooks shows that > someone has taken the time to examine possible races.. Someone, true. Open Software is about many eyes on each solution. I've heard nothing but "we haven't thought a lot about this" on this list. A little more review wouldn't hurt, would it? Hey, Seth... your patch closes one of those holes. WELL DONE. :) > > I don't think the kernel should claim value for the kernel by saying > that we help with race conditions; kernel races will still remain with > or without LSM. (Though, if anyone finds any races in the kernel while > working on LSM code, it might help our reputation some to point out > those races... :) Aren't race conditions one of the most glaring vulnerabilities? This is about security. At very least, a discussion about race conditions and LSM should be undertaken... for the good of Linux Security. > > Cheers! :) > Salut! 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 : Mon Oct 01 2001 - 18:53:48 PDT