This is a slightly cleaned up version of the patchset posted last year (https://lkml.org/lkml/2014/2/26/554). I've made a couple of minor changes based on feedback, but otherwise this is pretty much the same. Some things I *haven't* done:
1) Disabled CAP_SYS_RAWIO Disabling CAP_SYS_RAWIO has the fun side effect of disabling things like CPU microcode loading. Given that the microcode is already signed and the CPU validates that, this isn't helpful. There's just too many cases where CAP_SYS_RAWIO is required for features that are outside the scope of ensuring that the kernel can't be tampered with. In addition, there are features that don't require CAP_SYS_RAWIO which should be blocked. 2) Disabled CAP_SYS_RAWIO but whitelisted specific CAP_SYS_RAWIO features This was Alan's suggestion - change capable() to check whether the capability requested was blacklisted, and then add a capable_always() that ignored the blacklist. In this scenario, /dev/mem would still use capable(CAP_SYS_RAWIO) and would be denied, but the microcode loader would use capable_always(CAP_SYS_RAWIO) and would be permitted. This changes certain behavioural expectations (eg, having CAP_SYS_RAWIO would no longer be sufficient to pass capable(CAP_SYS_RAWIO)) and would still hit the problem of features that should be blocked but don't currently require CAP_SYS_RAWIO. I think this is fundamentally more confusing than the approach I've implemented. 3) Done one of the above and added new CAP_SYS_RAWIO checks This would handle the case of features that should be blocked but which don't currently require CAP_SYS_RAWIO, but would break any userspace that has dropped privileges and expects to be able to use these features even in the case that this feature isn't enabled. I don't think it's beneficial. 4) Used the word "measured" Nothing is being measured. A patchset basically equivalent to this is already used by most major Linux distributions, so it would be nice to either get this merged or have feedback from a relevant maintainer as to how they'd like it to be implemented instead. -- Matthew Garrett | <matthew.garr...@nebula.com> -- 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/