On 02/08/2013 01:14 PM, Josh Boyer wrote: > On Fri, Feb 8, 2013 at 4:07 PM, Matthew Garrett > <matthew.garrett-05XSO3Yj/jvqt0dzr+a...@public.gmane.org> wrote: >> On Fri, 2013-02-08 at 13:02 -0800, Kees Cook wrote: >> >>> I don't find it unreasonable to drop all caps and lose access to >>> sensitive things. :) That's sort of the point, really. I think a cap >>> is the best match. It seems like it should either be a cap or a >>> namespace flag, but the latter seems messy. >> >> Yeah, I think it's an expected outcome, but it means that if (say) qemu >> drops privileges, qemu can no longer access PCI resources - even on >> non-secure boot systems. That breaks existing userspace. > > Right. We've had a few reports in Fedora of things breaking on non-SB > systems because of this. The qemu one is the latest, but the general > problem is people think dropping all caps blindly is making their apps > safer. Then they find they can't do things they could do before the new > cap was added. It's messy.
Why not require CAP_COMPROMISE_KERNEL to open (with O_RDWR or O_WRONLY) /dev/msr? After all, sudo </dev/null >/dev/msr will cause a privileged write() call on the fd as long as the capability is in your bounding set. --Andy -- 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/
