[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1394746314.27846.4.camel@x230>
Date: Thu, 13 Mar 2014 21:31:55 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"hpa@...or.com" <hpa@...or.com>,
"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown
On Thu, 2014-03-13 at 21:26 +0000, One Thousand Gnomes wrote:
> > 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.
>
> Actually I know how to describe the problem better.
>
> Whitelist v Blacklist.
>
> Going around adding extra cases for CAP_SYS_RAWIO is a fails insecure
> model. Going around adding CAP_SYS_RAWIO || CAP_SYS_RAWIO_SEC is a 'fails
> secure' case.
We've already been through this. We can't add new capabilities. It
breaks existing userspace.
--
Matthew Garrett <matthew.garrett@...ula.com>
Powered by blists - more mailing lists