[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140313212647.7412aadf@alan.etchedpixels.co.uk>
Date: Thu, 13 Mar 2014 21:26:47 +0000
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Matthew Garrett <matthew.garrett@...ula.com>
Cc: "jmorris@...ei.org" <jmorris@...ei.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.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 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.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists