Re: [PATCH] security: unconditionally call Yama

[Eric W. Biederman]

Kees Cook <keescook@xxxxxxxxxxxx> writes:

> On Fri, Aug 31, 2012 at 8:31 PM, Eric W. Biederman
> <ebiederm@xxxxxxxxxxxx> wrote:
>> Eric Paris <eparis@xxxxxxxxxxxxxx> writes:
>>
>>> On Fri, Aug 31, 2012 at 4:59 PM, Eric W. Biederman
>>> <ebiederm@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/