Quoting Chris Wright (chrisw@private): > 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). So it sounds like what you'd like is something like: 1. split lsm hooks explicitly into state update (or labeling if you prefer) hooks and authorization hooks 2. state update hooks still get the info they get now, ie inode, etc. 3. lsm provides some api for labeling objects inside the state update hooks 4. the authorization hooks no longer send full inodes and task pointers, but only send the labels which a module has assigned to those objects. 5. ... but the label data can still be structs etc (not just an integer or char *). This could of course be abused by modules to just point back to the inode and task, to bypass these controls... 6. modules can still be dynamically loaded This would also mean that 7. The update hooks could become more general - not just for LSM, but shared with audit and integrity measurement hooks. Is that the kind of thing you're talking about, Chris? thanks, -serge
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 06:49:57 PDT