On Don, 19 Apr 2001 Magosányi Árpád wrote: > A levelezőm azt hiszi, hogy Crispin Cowan a következőeket írta: > > Stephen Smalley wrote: > > impose a set of policy models (Type Enforcement, RBAC). I think Linus' > > view of "generic solution" is much more draconian, where "generic > > solution" includes *no* solution, i.e. kick security to the curb if you > > don't want/need it. > > If we use hooks, it is a matter of kernel config option CONFIG_NO_SECURITY_HOOKS, > or CONFIG_NO_SECURITY. No doubt, it should be configurable. However, when it comes to end users, the distributions will have to decide which switches are on, and our solution should make them include the hooks. > > > But if you want a truly > > > generic solution, it makes more sense to convert the SELinux and/or > > > RSBAC interface to meet Linus' style than to start from scratch and > > > have to re-argue about every hook. > > > > I'm reasonably sure that this is not what is wanted in a "generic > > solution". Rather, the generic solution should enable SELinux or > > RSBAC to be employed if desired. > > Yes, we need the right set of hooks. To figure out which is the right set, > a very good way is to start converting all implementations to lkms. After > you all came up with your sets, you should be locked into a room with lotsa > coffe, and released only with the set agreed upon. We should be able to agree within less than a week ;) Honestly, I do not think that we are too far apart - the GACI discussion showed that. > As far as I can see, your hardest time will not be about the place of the > hooks, but about the "which hooks, and how many". That is more difficult, specially the 'how many'. It will be hard to decide which ones needed by only few existing models will be left out. We might end up with a lot of config options. > I guess that some kernel options like CONFIG_MINIMAL_SECURITY_HOOKS > and CONFIG_SECURITY_HOOKS_LOG would ease the tension a lot. S.a.: it might be necessary to trim the sets for certain purposes, e.g. logging, or extensive, immediately revokable access control. > > However, I have been told that the SELinux people doubt the viability of > > a LKM interface for their package, and I've seen the RSBAC people claim > > in public that they don't believe that LSM is sufficient for their > > needs. So, I advocate LSM providing the hooks for SELinux and RSBAC if > > and only if they intend to port to it. > > This is The Right Way(TM). If any of them would not come out with an LSM > version, they would soon be found themselves with a below-criticall-mass > user base. And I really don't see the LKM or not LKM problem as serious > as some others. Part is unrelated (the boot problem), and the other parts > will be handled in short time with good engineering practices. Provided we find a solution for the important boot problem, we still need a huge set of hooks for complete model implementations. I have a real problem with your 'let those who care do the work'. The existing projects are not all well funded with huge ressouces of man power. There is a big risk of loosing some good approaches just because they are not taken into account at design time. Take this list as an example: Who of us spare time developers can do additional development work while following such an amount of discussion threads and mails? I am already skipping some probably interesting threads out of lack of time. > > > 3) Linus also said that he would be willing to accept security IDs > > > into a number of kernel data structures. Security IDs, if you're not > > > familiar, are a policy-independent data type for security labels > > > already used in SELinux. We already know what data structures need > > > security IDs for SELinux, since it is already implemented. RSBAC > > > used a different approach (using separate mappings for binding > > > labels to subjects and objects), but they could probably easily > > > generate a list of the data structures they would like to be able > > > to directly tag. > > > > This is a serious issue. Should there be an LSM-wide standard for > > security IDs? Or should LSM security IDs just be opaque blobs, and > > semantics are imposed by the LSM module that is installed? I have a hard > > time convincing myself that we've seen the last word in security IDs. > > That plus the above stated fact that RSBAC and SELinux uses different > > notions of IDs suggests that we should go with opaque blobs. > > Well, there should be a LSM-wide standard for security IDs, and > (provided that the majority of developers won't learn from the > recent Amon Ott - Stephen Smalley match [0:1 IMHO]), the standard > will be about opaque blobs (which have some size impact, but I as > a user willing to pay it for the fact that we have an architecture). Some opaque (void *) per registered module would be fine for RSBAC. There is also no real problem in maintaining an indirect list with 64 bit IDs, apart from slowing down the lookup. > > My main problem with that is that SubDomain is 1/10th the size of > > See above. The interface should be small, no doubt. However, in most implementations (like SELinux, RSBAC), it is already rather small. In RSBAC the size comes with - persistent data structure handling (how will that be solved?) - complex access control models E.g. the RSBAC patch part is little more than 200K, with lots of context (many small patches), white spaces and comments. > [cut examples] > Distilling the best of all breads is a non-trivial task, and involves > some compromises from all parties, but very important. It is certainly non-trivial, the compromises will certainly hurt and it will be a lot of work to adapt to the result. Still, I agree in it being important (why I initiated the GACI discussion). Amon. _______________________________________________ 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 : Thu Apr 19 2001 - 03:01:36 PDT