From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: Eric Paris <eparis@parisplace.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org,
James Morris <james.l.morris@oracle.com>,
Eric Paris <eparis@redhat.com>, Jiri Kosina <jkosina@suse.cz>,
John Johansen <john.johansen@canonical.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] security: unconditionally call Yama
Date: Fri, 31 Aug 2012 21:05:37 -0700 [thread overview]
Message-ID: <87oblqbd66.fsf@xmission.com> (raw)
In-Reply-To: <CAGXu5jKD0MDetYuavSmXjDB3t3cYEkiEoEY-bAMyhFrmTaA6FA@mail.gmail.com> (Kees Cook's message of "Fri, 31 Aug 2012 20:42:58 -0700")
Kees Cook <keescook@chromium.org> writes:
> On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Eric Paris <eparis@parisplace.org> writes:
>>
>>> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
>>> <ebiederm@xmission.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
next prev parent reply other threads:[~2012-09-01 4:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 21:31 [PATCH] security: unconditionally call Yama Kees Cook
2012-08-31 21:39 ` Alan Cox
2012-08-31 22:49 ` Eric Paris
2012-08-31 23:59 ` Eric W. Biederman
2012-09-01 3:03 ` Eric Paris
2012-09-01 3:31 ` Eric W. Biederman
2012-09-01 3:42 ` Kees Cook
2012-09-01 4:05 ` Eric W. Biederman [this message]
2012-09-02 7:37 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87oblqbd66.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dan.carpenter@oracle.com \
--cc=eparis@parisplace.org \
--cc=eparis@redhat.com \
--cc=james.l.morris@oracle.com \
--cc=jkosina@suse.cz \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.