On Fri, 13 Oct 2017 15:03:10 +0000 > Take off your "kernel" hat and put on a "customer" hat for a few moments > while I try to put this in practical terms why the whitelist approach doesn't > scale for what I'm trying to do. As a customer I'm more worried about someone trashing my system or breaking my security. > So considering the above isn't offering stuff like this a decision better made by the OEM? > If the OEM doen't want customers to be able to modify something we don't offer it in the > manageability interface. If the kernel community doesn't want people to be > modifying something the OEM does offer, it can just as well be blacklisted in the > kernel driver like the current filtering approach offers. So you implement the rule if (whitelisted & (capabilities && whitelist->capability_need) == whitelist->capability_need)) return ALLOWED; if (capable(CAP_SYS_RAWIO)) return ALLOWED; return NO This puts you in the position where - known tools work and can sometimes be unprivileged. Privileged tools with enough priv to screw the machien can work anyway. Which is better than the starting point You could further enhance this by having a CAP_SYS_RAWIO interface to add whitelist entries, or to add an eBPF filter that can also make decisions for you. Now you've got the ability to push a policy update. Alan
