* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > +config PROTECTED_STICKY_SYMLINKS > > + bool "Protect symlink following in sticky world-writable directories" > > + default y > > + help > > + A long-standing class of security issues is the symlink-based > > + time-of-check-time-of-use race, most commonly seen in > > + world-writable directories like /tmp. The common method of > > + exploitation of this flaw is to cross privilege boundaries > > + when following a given symlink (i.e. a root process follows > > + a malicious symlink belonging to another user). > > + > > + Enabling this solves the problem by permitting symlinks to be > > + followed only when outside a sticky world-writable directory, > > + or when the uid of the symlink and follower match, or when > > + the directory and symlink owners match. > > This is all quite misleading. One would expect that > CONFIG_PROTECTED_STICKY_SYMLINKS turns the entire feature on > or off permanently. ie, it controls whether the code is > generated into vmlinux in the usual fashion. But it's not > that at all - the user gets the feature whether or not he > wants it, and this variable only sets the initial value. > > Why are we forcing the user to have the feature if he doesn't > want it, btw? Basing on the (not yet fully confirmed) assertion that no apps are broken by this change but exploits, I'd argue that this is actually the sane and correct semantics for symlinks - i.e. we want this to be the default Linux behavior - not just a 'feature'. That way the configuration knobs are compat settings in essence - in case some app cares. If people disagree and want it default off and as a separate feature then it has to be modularized out some more. There's notable silence from VFS folks on all this so Kees made an educated guess. It might be wrong. > And we appear to be enabling the feature if CONFIG_PROC_FS=n, > which might not be terribly useful? It can still be useful if it's default on - just cannot be turned off via /proc/sys/, right? The combination that is not so useful is when it's off and there's !PROC_FS. If it's a compat feature then i wouldnt bother about it. If it's a separated out modular feature in a separate .c file then it can all be properly shaped via Kconfig dependencies. 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
