On 2/27/2013 8:43 AM, Paul Moore wrote: > On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote: >> On 2/26/2013 1:21 PM, Paul Moore wrote: >>> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote: >>>> The set of LSMs, the order they are invoked, which LSM >>>> uses /proc/.../attr/current and which LSM uses Netlabel, >>>> XFRM and secmark are all determined by Kconfig. You can >>>> specify a limited set of LSMs using security= at boot, >>>> but not the networking configuration. >>> That's unfortunate. I'm _really_ not in favor of that, I would much >>> rather see the non-shared LSM functionality assigned at the same time as >>> the stacking order. I'm not sure I'd NACK the current approach, or even\ >>> if anyone would care that I did, but that is how I'm currently leaning >>> with this split (build vs runtime) selection. >> I'm not against that approach. How would you see it working? >> >> The distro compiles in all the LSMs. >> They specify that SELinux gets xfrm and secmark. >> They specify the Smack gets Netlabel. >> They tell (the new and improved) AppArmor to eschew networking. >> They specify a boot order of "selinux,smack,apparmor,yama" >> (They left off tomoyo for tax purposes). >> >> On the boot line, the user types "security=apparmor". >> >> What should happen? > Okay, I misunderstood what was specified at boot time; I thought the stacking > order could be defined at boot but based on your example I'm guessing the > stacking order is defined at compile time and you can only enable/disable LSMs > at boot? Well, no. It looks as if I gave a poor example. "security=apparmor,tomoyo,selinux" is legitimate and indicates that AppArmor goes first, then TOMOYO, then SELinux. No LSM gets NetLabel because that was allocated to Smack. SELinux gets XFRM and secmark. >>>> Tetsuo is lobbying for loadable security modules. I am >>>> doing my best to leave everything in a state where some >>>> soul braver than I might pick that up after I'm done. >>>> I do not have any intention of supporting on the fly >>>> or heuristically determined networking. >>> Well, if that is the case I think the first-come-first-served approach to >>> the non-shared functionality probably makes the most sense. I understand >>> why it might not be ideal in ever situation but it is predictable. >> Would you have the same opinion if SELinux were last, instead of first? > Yes. > > In fact, considering the example above, and also assuming I'm understanding it > correctly, I think I am more in favor of the first-come-first-served approach > since you can enable/disable LSMs at boot. Imagine if you gave one LSM all > the non-shared functionality but disabled it at boot in favor of another LSM > which could make use of some of this functionality but was denied due to the > compile time option. This seems much more useful to me. > >>>>>> I'm trying not to make too many architectural changes to the >>>>>> code around the LSM mechanism itself. I don't see that as cost >>>>>> effective or likely to be popular. If the implication of that is >>>>>> that there are certain configurations that are unsupportable but >>>>>> that have plausible alternatives I think it will do for phase I. >>>>> That statement is vague enough that I can't really say yes or no to it, >>>>> but I will stick by my previous comments about the network access >>>>> controls. >>>> Ah. I want to create a useful system. I want to create it >>>> reasonably short order. I am willing to forgo supporting >>>> some configuration options to reduce the project time. In >>>> particular, I hope to avoid mucking up other people's code >>>> as that is a sure fire way to bog a project down. >>> Usefulness is paramount of course >> Agreed >> >>> and quickness is nice, >> If it drags on too long the boss gets cranky. And "labelled" NFSv4.2 >> gets done. And the list macros get reworked. And .... >> >>> but I do think it takes a back seat to "the right solution". >> If I had two years and didn't have to worry about anyone else's >> changes and weren't beholden to retaining some of the past's more >> interesting design choices I'd be more concerned about "right" than >> "good". >> >>> We're all going to have to live with this f-o-r-e-v-e-r, >> Assuming it gets adopted. It will have to be good enough for that. >> There is no guarantee on that. >> >>> or at least what will surely seem like it, so I'd much rather we take the >>> time to make sure we beat out as much ugly as we can before it is merged. >> I'm with you there. I just hope the ugly hasn't been lifting weights. > February is "fitness month". -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
