From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 00/12] One more attempt at useful kernel lockdown Date: Mon, 09 Sep 2013 12:56:15 -0700 Message-ID: <522E27DF.8020409@zytor.com> References: <1378741786-18430-1-git-send-email-matthew.garrett@nebula.com> <19562.1378747124@turing-police.cc.vt.edu> <27562.1378753264@turing-police.cc.vt.edu> <522E2487.90109@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-security-module-owner@vger.kernel.org To: Josh Boyer Cc: Valdis Kletnieks , David Lang , Matthew Garrett , "Linux-Kernel@Vger. Kernel. Org" , Kees Cook , Greg KH , "linux-efi@vger.kernel.org" , James Morris , linux-security-module List-Id: linux-efi@vger.kernel.org >> >> I.e. capabilities ;) > > Circles. All I see here are circles. > > Having lived an entire release with a capabilities based mechanism for > this in Fedora, please no. > > And if you are talking about non-POSIX capabilities as you mentioned > earlier, that seems to be no different than having securelevel being a > bitmask of, well, levels. I don't have much opinion on securelevel > being a big hammer or a bitmask of finer grained things, but I do > think it's a more manageable way forward. Calling the implementation > "capabilities" seems to just be unnecessarily confusing. > This is the term "capability" in the general sense, not the POSIX implementation thereof. -hpa