On Wed, Feb 7, 2018 at 12:48 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Tue, 2018-02-06 at 17:18 -0500, Paul Moore wrote: ... >> While I don't think we need to tackle this as part of the >> encapsulation work, this is another reminder that we should look into >> breaking the separation between the security server and the >> Linux/hooks code. I understand there were historical reasons for >> this >> split, but I think all of those reasons are now gone, and further I >> think enough Linux'isms have crept into the security server that the >> separation is no longer as meaningful as it may have been in the >> past. > > I think we want to retain some degree of encapsulation of the policy > logic and data structures, which is what the security server is > supposed to provide. That allows us to evolve that logic and > structures without impacting the object label management and permission > enforcement code. Separation of policy from mechanism. I don't mind > nativizing the security server for Linux, and where appropriate, > allowing some optimization of the interfaces between it and the rest of > the SELinux code, but I wouldn't want to e.g. directly expose the > policydb to the rest of the code. There has been some leakage of > policy awareness outside the security server in the past but I view > that as a mistake that ought to be corrected over time. I agree that a level of abstraction between the policydb code and the enforcement code is a good thing, but I think there are some boundaries between the hook code and the security server that we could do without. Once again, not really part of this work, just popped up in my head again while looking at these patches. -- paul moore www.paul-moore.com
