* Kees Cook <keescook@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
