• Eric W. Biederman's avatar
    mnt: Correct permission checks in do_remount · 9566d674
    Eric W. Biederman authored
    While invesgiating the issue where in "mount --bind -oremount,ro ..."
    would result in later "mount --bind -oremount,rw" succeeding even if
    the mount started off locked I realized that there are several
    additional mount flags that should be locked and are not.
    
    In particular MNT_NOSUID, MNT_NODEV, MNT_NOEXEC, and the atime
    flags in addition to MNT_READONLY should all be locked.  These
    flags are all per superblock, can all be changed with MS_BIND,
    and should not be changable if set by a more privileged user.
    
    The following additions to the current logic are added in this patch.
    - nosuid may not be clearable by a less privileged user.
    - nodev  may not be clearable by a less privielged user.
    - noexec may not be clearable by a less privileged user.
    - atime flags may not be changeable by a less privileged user.
    
    The logic with atime is that always setting atime on access is a
    global policy and backup software and auditing software could break if
    atime bits are not updated (when they are configured to be updated),
    and serious performance degradation could result (DOS attack) if atime
    updates happen when they have been explicitly disabled.  Therefore an
    unprivileged user should not be able to mess with the atime bits set
    by a more privileged user.
    
    The additional restrictions are implemented with the addition of
    MNT_LOCK_NOSUID, MNT_LOCK_NODEV, MNT_LOCK_NOEXEC, and MNT_LOCK_ATIME
    mnt flags.
    
    Taken together these changes and the fixes for MNT_LOCK_READONLY
    should make it safe for an unprivileged user to create a user
    namespace and to call "mount --bind -o remount,... ..." without
    the danger of mount flags being changed maliciously.
    
    Cc: stable@vger.kernel.org
    Acked-by: default avatarSerge E. Hallyn <serge.hallyn@ubuntu.com>
    Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    9566d674
namespace.c 73.6 KB