Quoting Stephen Smalley (sds@private): Thanks for your comments, Stephen. All right on, of course. > Minor issue: It would be nice if we could ensure that capabilities and > cap_stack are not simultaneously enabled; after applying the patches and True, I've done it too... I was hesitant about adding an 'unselect' option to the Kconfig language, but it occurs to me using "depend on x=n" should work. > Stacker lacks a settime hook, possibly others but I didn't see any other > gaps. More generally, this adds another step in adding a new hook to > LSM that everyone needs to be aware of; possibly should be noted in > security.h. Would be useful to have a script for checking stacker hooks > against security.h or dummy module. On Friday I implemented a check when stacker is loaded, but that was very unsatisfying. Only options at that point are crash the kernel or print an error message and return -EINVAL, which is so early in the boot process that I couldn't notice the error, and the kernel just proceeded to load SELinux only. As you say I'll add a little script called from the makefile, and have it run on both dummy and stacker. > The stacker warnings about preventing unloading are amusing but have to > go, of course. Stacker should likely be displaying something upon > successful registration to indicate that it is the primary LSM. Will do. > I'd expect an objection ultimately to the limitation of getprocattr and > setprocattr to SELinux and the SELinux-specific handling in stacker, > although I'm certainly not excited about having to update userspace to > deal with multiple attributes via that interface. Oh, as of very recently, I'm actually able to volunteer to do that :) So I'll happily update whatever I can find, though I'm not sure where all the patches should go and what all needs to be patched. Clearly selinuxfs and procutils. I'll dig around. (I had been considering just leaving procattr unaddressed, but was told last friday that another module will in fact be able to make good use of it) > An obvious concern is what open source modules are going to use this to > stack with SELinux. I see that the integrity measurement module has > been posted to lkml, but it only implements a handful of hooks and is > not an access control module. Which raises the question of whether it > should be using LSM or its own set of specialized measurement hooks. I'm not very "in the loop", but I understand there is another similar TPM based module which performs authorization, which should be released soon. It actually consists of two modules and so uses stacker just by itself. Of course there is digsig for people without TPMs. And seclvl. > One of my performance-related concerns is whether there is any impact on > scalability to large numbers of processors, as in KaiGai's earlier > testing for the AVC RCU work. I'd tend to not expect a significant > impact given the relatively lockless approach, but one never knows until > you see the data. Are you able to perform such testing, or perhaps > someone should ask KaiGai if he could repeat such testing with your > patches applied? I should be able to test on 16 cpus this week. If you'd prefer also 32-cpu, then I will mail KaiGai. thanks, -serge
This archive was generated by hypermail 2.1.3 : Mon May 23 2005 - 04:50:29 PDT