linux-kernel - Re: [PATCH] security: unconditionally call Yama

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87oblqbd66.fsf@xmission.com>
Date:	Fri, 31 Aug 2012 21:05:37 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kees Cook <keescook@...omium.org>
Cc:	Eric Paris <eparis@...isplace.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>, Jiri Kosina <jkosina@...e.cz>,
	John Johansen <john.johansen@...onical.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] security: unconditionally call Yama

Kees Cook <keescook@...omium.org> writes:

> On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> Eric Paris <eparis@...isplace.org> writes:
>>
>>> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
>>> <ebiederm@...ssion.com> wrote:
>>>
>> Having taken the time now to vet Yama ugh.  Having Yama enabled if
>> simply compiled in breaks using gdb to attach to a process runing
>> in another window.
>>
>> Talk about something you don't want to surprise someone with.
>>
>> It is very much not ok to have that be enabled by default just
>> because it happens to be compiled in.
>
> I think it is better to look at the kernel's defaults from the
> perspective of the user, not the developer.

It is best to look at the kernel defaults with respect to regressions
from previous behavior.  And YAMA uncondionally enabled and restricting
ptrace when compiled simply in, is most definitely a regression from
previous behavior.  And it is most definitely is not a behavior no
one cares about.

> If we only looked to the
> developer, we'd turn on all the debugging by default. No end user
> wants that. It's much easier for a developer to twiddle configs and
> sysctls.

If you want to change the default behaior of the kernel provide a
config option that is specifically about changing the behavior.

But changing the behavior by default and compiling in the code
are two very very different things, and they should continue to be.

> Given that several distros use (or want to use) Yama, I think that's
> reason enough for this. I think it's important for us to take a
> practical approach here, and having the big LSMs each hook Yama
> instead of doing this in a single global place will make it needlessly
> duplicated code.

People wanting to use a feature is certainly an argument for figuring
out how to do it well.  It most definitely is not a reason for randomly
breaking long established kernel features when they happen to run
make oldconfig and telling other people to just deal with it.

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