On Thu, Oct 17, 2013 at 4:30 AM, Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> wrote: > On Thu, Oct 17, 2013 at 07:02:17PM +1100, James Morris wrote: >> This seems like a regression in terms of separating mechanism and policy. >> >> We have several access control systems available (SELinux, at least) which >> can implement this functionality with existing mechanisms using dynamic >> policy. >> >> I'm concerned about the long term architectural impact of a proliferation >> of arbitrary hard-coded security policies in the kernel. I don't >> understand the push in this direction, frankly. > > The biggest risk in LSM stacker is really to become backdoor for very product > dilated kernel changes that are not accepted to the mainline kernel. I think > having LSM stacker would be benefical but barrier should be set very high > for "one-shot" modules. > > One big benefit that I see in LSM stacker is not at least directly security > related. It would be perfect integration tool when you want for example > provide Android run-time in an OS that uses AppArmor or SMACK as its security > framework.
I think of stacking as a way to help people do quick prototyping of security changes without getting in the way of their distro's MAC. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
