linux-kernel - Re: [RFC] capabilities: Ambient capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 14 Mar 2015 17:04:35 -0700
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	"Ted Ts'o" <tytso@....edu>, Andrew Lutomirski <luto@...nel.org>,
	Andrew Morton <akpm@...uxfoundation.org>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Linux API <linux-api@...r.kernel.org>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	Aaron Jones <aaronmdjones@...il.com>,
	Christoph Lameter <cl@...ux.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Markku Savela <msa@...h.iki.fi>,
	Kees Cook <keescook@...omium.org>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [RFC] capabilities: Ambient capabilities

On Sat, Mar 14, 2015 at 3:55 PM, Andy Lutomirski <luto@...capital.net> wrote:
> It occurs to me that my previous reply was unnecessarily long and
> missed the point.  Trying again:
>
> On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan <morgan@...nel.org> wrote:
>> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski <luto@...capital.net> wrote:
>>> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan <morgan@...nel.org> wrote:
>>>> My Nack remains that you are eliminating the explicit enforcement of
>>>> selective inheritance. A lockable secure bit protecting access to your
>>>> prctl() function would address this concern.
>>>
>>> Would a sysctl or securebit that *optionally* allows pA to be disabled
>>> satisfy you?
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It would be kind of nice to remove your nack.  I think that the above
> is the relevant question.  Could you answer it?

I thought I did. Please implement a lockable secure bit and I will
remove my Nack.

I don't understand your confusion. Perhaps you are defining
*optionally* in a way I don't follow? Perhaps you are saying that you
want the default behavior of kernels to change to include your new
feature, and that you want the secure bit, when set, would put it into
pA suppressed mode?

Other folk are probably better at anticipating the ramifications of
changing default behavior. I'd prefer you default to pA being off, but
I shall remove my Nack either way if you implement a lockable secure
bit.

Clear enough?

Thanks

Andrew
--
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/