lkml.org 
[lkml]   [2012]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2012.1] fs: symlink restrictions on sticky directories
    From
    On Fri, Jan 6, 2012 at 1:58 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
    > On Fri, 6 Jan 2012 10:43:40 +0100 Ingo Molnar <mingo@elte.hu> wrote:
    >> * Andrew Morton <akpm@linux-foundation.org> 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.
    >
    > Maybe true for a general purpose computer, but someone who is making a
    > single-purpose device such as a digital TV or a wifi router won't want
    > it.
    > [...]
    > I'd have thought the way to configure this feature would be to have
    > CONFIG_PROTECTED_STICKY_SYMLINKS to control the code generation then a
    > 0 or 1 CONFIG_PROTECTED_STICKY_SYMLINKS_ENABLED to control the initial
    > setting.

    This seems like probably the best approach, though I dislike the
    silliness required in Kconfig to get a boolean into 1/0 form instead
    of set/unset in way that doesn't require the user to type "1" or "0".
    I'm happy to do it, though.

    -Kees

    --
    Kees Cook
    ChromeOS Security
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-01-06 19:37    [W:0.043 / U:0.264 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site