* James Morris (jmorris@private) wrote: > On Wed, 25 May 2005, Tony Jones wrote: > > But the LSM hooks aren't going to just dissapear. Under what you propose they > > will be replaced by other SELinux specific calls. How does this change the > > impact to core/other kernel maintainers when they make changes? They are > > still going to be faced with making changes near call points whose purpose > > they may not be overly familiar with. > > That's a good point. Yes, the SELinux specific calls would still be > there. > > The differences for cor maintainers would be: > > a) Clearer semantics, i.e. being able to trace the flow directly into the > SELinux code and be able to see exactly what's happening. I don't agree at all. If you can't follow a function pointer... In fact, I don't even agree that that's the semantic issue. I think the semantic issue is with the loose mechanism that information is passed from core to security module. It errs on passing too much, and relies on typeless data. If anything, the problem is the layer is too thin. So perhaps here's where our opinions converge. Everybody wants to do the same basic thing, control access between subject and object. Other core subsystems do much more to enforce semantic rules, lifetime rules, typed interfaces, cache maintainance, etc. on behalf of the users of the subsystem. So, ideally what the access control module should see is only the question we care about (does $subject get to take $action on $object). Unfortunately, reality strikes when you want to have security model specific ways to label $subject, interpret $action, and label $object). SELinux has done a great job at make the access request generic through the the avc. So, while you say drop LSM and just use SELinux, I would say push avc into LSM...it's pretty simimlar in the end... Problem is, you still have to deal with calling out to modules that want to do their own label management, have their own policy language, etc. This is where it starts to feel like you're just pushing the problem around. > b) Getting rid of LSM hooks which SELinux doesn't use (not sure how many, > but not a large amount). At any rate, neither of these (a, or b) are very strong reasoning for removal. I'll listen to real ideas on how to improve the semantics of core interfacing with security module (and no, I don't mean function pointers, I mean real interface semantics).
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 06:42:01 PDT