Yves, I will concede that the various access control systems are "more or less" equivalent, and I'm just really enthusiastic about grsec's, and the possibility of making it available to more people in Debian.
As a general matter, I regard the grsecurity RBAC as more comprehensive and easier to administer. It's highly automated, policies and ACLs are human-readable, implements least privilege, etc. It can also be used simultaneously with any other LSM. The following table obviously concerns way more than just the RBAC, but is still illuminating: https://grsecurity.net/compare.php In a separate thread you advocated standardizing around one solution, which I assume is AppArmor. Have you had any success at getting the AppArmor LSM to work on this kernel yet? I personally have not. If I had just those two options, I know which I would choose. I'd point out that SELinux support is compiled into the Debian kernel as well, though disabled by default. At the moment, grsec's RBAC is being actively disincluded, which is non-default. If one patches the kernel sources with grsecurity and runs `make menuconfig` and enables it using the Automatic configuration method, the RBAC will be available. To my mind, the choice of disabling it warrants more justification than the inverse, since this configuration is not quite what those who are already familiar with running grsec would expect. It would be a different matter if one could toggle the RBAC via sysctl, but that's not the case; it needs to be built in. If you do that, it's still going to be off by default (same as SELinux and AppArmor, they all require bootstrapping), as the gradm tool is required in order to enable it. I really don't see any issues that could result from simply offering the capability, and I don't think I'm the only one who uses it. I don't expect you to be convinced yet, so I may return to this thread with further arguments and justifications by and by.
