Re: [PATCH 00/12] One more attempt at useful kernel 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: 2540 bytes --]

On Mon, 2013-09-09 at 20:09 -0700, David Lang wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:

> > Someone adds a new "install_evil()" syscall and adds a disable bit. If I
> > don't disable it, I'm now vulnerable. Please pay attention to earlier
> > discussion.
> 
> so instead they add install_evil() and don't have it be disabled by your big 
> switch.

And that's a bug, so we fix it.

> > Describe the security case for disabling PCI BAR access but permitting
> > i/o port access.
> 
> Simple, I have some device that lives on those I/O ports that I want to be able 
> to use.

That's a great argument for permitting i/o port access. But in that
case, why are you disabling BAR access? You can use the i/o port access
to reprogram the device in question into a range you can modify, which
allows you to avoid the BAR restriction.

> > Because then someone disables selinux on the kernel command line.
> 
> If they can modify the command line, they can remove your command line switch to 
> turn this on.

Not in the secure boot case.

> If you really care about this, why are you using a bootloader that lets you 
> modify the kernel command line in the first place?

And then the user just modifies the configuration file instead.

> In any case, even if you make it impossible to change from the command line, you 
> won't prevent people from changing your system (unless you take control 
> completely away from them with TPM or similar)

That's fine. People are free to modify their own systems.

> remember that the system integrity checking of the original Tivo was defeated by 
> someone dong a binary patch to bypass a routine that they didn't understand that 
> took a lot of time, so they did a binary patch to the bios to speed up boot and 
> discovered that what they did was disable the system integrity checking.

That's why modern systems require signed firmware updates.

> users who own the systems are going to modify them and bypass any restrictions 
> you want to impose.

The idea isn't to produce something that's impossible for the owner of a
system to disable. The idea is to produce something that can't be used
to circumvent the security policy that the system owner has chosen.
Could you please give me the benefit of the doubt and assume that I'm
not completely unaware of how computers work?

-- 
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¥