lkml.org 
[lkml]   [2012]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2012.2] fs: symlink restrictions on sticky directories

* Kees Cook <keescook@chromium.org> wrote:

> >> > I think I disagree with this. __If the person compiling
> >> > the kernel includes the feature in his kernel via the
> >> > time-honoured process of "wtf is that thing? __Yeah,
> >> > whatev", it gets turned on by default. __This could
> >> > easily result in weird failures which would take a *long*
> >> > time for an unsuspecting person to debug.
> >> >
> >> > Would it not be kinder to our users to start this out as
> >> > turned-off-at-runtime unless the kernel configurer has
> >> > deliberately gone in and enabled it?
> >>
> >> There was a fair bit of back-and-forth discussion about it.
> >> Originally, I had it disabled, but, IIRC, Ingo urged me to
> >> have it be the default. I can sent a patch to disable it if
> >> you want.
> >
> > What is the reasoning behind the current setting?
>
> The logic is currently:
>
> - from a security perspective, enabling the restriction is
> safer
> - in the last many years, nothing has been found to be
> broken by this restriction
>
> The evidence for the second part mostly comes from people's
> recollections using OpenWall, grsecurity, and lately Ubuntu. I
> can speak from the Ubuntu history, which is that in the 1.5
> years the symlink restriction has been enabled, no bugs about
> it were reported that I'm aware of (and I was aware of, and
> fixed, several of bugs in the other restrictions that are
> carried in Ubuntu).

I'd say all this current evidence suggests that it should be on
by default - having it off only helps attackers and hermite
systems.

So at minimum we should wait until the first regression report
before twiddling it off. I could be wrong though.

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-02-19 13:35    [W:0.042 / U:1.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site