On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > No. Say someone adds an additional lockdown bit to forbid raw access to
> > mounted block devices. The "Turn everything off" approach now means that
> > I won't be able to perform raw access to mounted block devices, even if
> > that's something that my use case relies on.
>
> I was meaning that if you only turn off features that you know about, the
> addition of a new thing that can be disabled doesn't make you any worse off
> than
> you were.
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 if you only have a single bit, how do you deal with the case where that
> >> bit
> >> locks down something that's required? (your reason for not just setting
> >> all bits
> >> in the first approach)
> >
> > Because that bit is well-defined, and if anything is added to it that
> > doesn't match that definition then it's a bug.
>
> it may be well defined, but that doesn't mean that it actually matches what
> the
> system owner wants to do.
If it doesn't match what the system owner wants to do, the system owner
doesn't set it. The system owner uses a more appropriate security
mechanism instead.
> The idea that the programmer can possibly anticipate all possible needs and
> provide a switch for exactly that need is just wrong. Users will have needs
> that
> you never thought of. The best systems are the ones where the creators look
> at
> what users are doing and react with "I never imagined doing that"
Describe the security case for disabling PCI BAR access but permitting
i/o port access.
> > Anything more granular means that you trust your userspace, and if you
> > trust your userspace then you can already set up a granular policy using
> > the existing tools for that job. So just use the existing tools.
>
> If you can't trust your userspace, how do you know that the userspace has set
> the big hammer flag in the first place? if you can trust it to throw that
> switch, you can trust it to throw multiple smaller switches.
Hence the final patch in the series, and hence also the suggestion for
exposing it as a command line option that can be set by the bootloader
during an attested boot.
> >> And if SELinux can do the job, what is the reason for creating this new
> >> option?
> >
> > Because you can't embed an unmodifiable selinux policy in the kernel.
>
> Why not, have the policy set in an initramfs that's part of the kernel and
> have
> part of that policy be to block all access to the selinux controls.
Because then someone disables selinux on the kernel command line.
--
Matthew Garrett <matthew.garr...@nebula.com>
N�����r��y����b�X��ǧv�^�){.n�+����{�y����^n�r���z���h�����&�� �G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�
