Re: Trusted kernel patchset for Secure Boot lockdown

[Matthew Garrett <matthew.garrett@nebula.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1688 bytes --]

On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:

> I'll take it, but there's unanswered review feedback (your response to the 
> first question), and Alan raised some doubts about the patches which I'm 
> not sure have been resolved.

The remaining opens seem to be CAP_SYS_RAWIO and firmware signing?
Ironically, disabling CAP_SYS_RAWIO disables firmware loading…

The problem with CAP_SYS_RAWIO is that its semantics were never
sufficiently well documented, and as a result it's a mixture of "This is
incredibly dangerous" and "We replaced a check for uid 0 with whichever
capability seemed to have the most appropriate name". I've gone through
all the uses of CAP_SYS_RAWIO and added additional checks to the generic
ones that seem appropriate. There's a couple of old drivers that use it
to gate access to features that potentially allow arbitrary DMA and it
might be worth cleaning those up, but the only general case I haven't
modified is the ability to send arbitrary SCSI commands from userspace.
My understanding is that endpoints aren't going to be able to DMA to
arbitrary addresses, so that doesn't seem like a problem.

On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
functionality - firmware loading and the fibmap ioctl are probably the
most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
userspace expectations, so we're kind of stuck there.

As for signed firmware, I'm looking forward to Kees' work on that.

-- 
Matthew Garrett <matthew.garrett@nebula.com>
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥