Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKYSRqsHo8rqvyR1ZLQ2MT+UnG=F4_RTEp7Sq9q9qsPtw@mail.gmail.com>
Date: Tue, 27 Feb 2018 11:47:46 -0800
From: Kees Cook <keescook@...omium.org>
To: Salvatore Mesoraca <s.mesoraca16@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>, 
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, Alan Cox <gnomes@...rguk.ukuu.org.uk>, 
	Alexander Viro <viro@...iv.linux.org.uk>, David Laight <David.Laight@...lab.com>, 
	Ian Campbell <ijc@...lion.org.uk>, Jann Horn <jannh@...gle.com>, 
	Matthew Wilcox <willy@...radead.org>, Pavel Vasilyev <dixlor@...il.com>, 
	Solar Designer <solar@...nwall.com>, "Eric W. Biederman" <ebiederm@...ssion.com>, 
	"Tobin C. Harding" <me@...in.cc>
Subject: Re: [PATCH v4] Protected FIFOs and regular files

On Tue, Feb 27, 2018 at 3:00 AM, Salvatore Mesoraca
<s.mesoraca16@...il.com> wrote:
> Disallows open of FIFOs or regular files not owned by the user in world
> writable sticky directories, unless the owner is the same as that of
> the directory or the file is opened without the O_CREAT flag.
> The purpose is to make data spoofing attacks harder.
> This protection can be turned on and off separately for FIFOs and regular
> files via sysctl, just like the symlinks/hardlinks protection.
> This patch is based on Openwall's "HARDEN_FIFO" feature by Solar
> Designer.
>
> This is a brief list of old vulnerabilities that could have been prevented
> by this feature, some of them even allow for privilege escalation:
> CVE-2000-1134
> CVE-2007-3852
> CVE-2008-0525
> CVE-2009-0416
> CVE-2011-4834
> CVE-2015-1838
> CVE-2015-7442
> CVE-2016-7489
>
> This list is not meant to be complete. It's difficult to track down
> all vulnerabilities of this kind because they were often reported
> without any mention of this particular attack vector.
> In fact, before hardlinks/symlinks restrictions, fifos/regular
> files weren't the favorite vehicle to exploit them.
>
> Suggested-by: Solar Designer <solar@...nwall.com>
> Suggested-by: Kees Cook <keescook@...omium.org>
> Signed-off-by: Salvatore Mesoraca <s.mesoraca16@...il.com>
> ---
>
> Notes:
>     Changes in v3:
>         - Fixed format string for uid_t that is unsigned
>           (suggested by Jann Horn).
>     Changes in v4:
>         - Some English fixes (suggested by Tobin C. Harding).
>         - The original patchset has been split to help this part
>           land upstream (suggested by Solar Designer).
>
>  Documentation/sysctl/fs.txt | 36 ++++++++++++++++++++++++++
>  fs/namei.c                  | 61 ++++++++++++++++++++++++++++++++++++++++++---
>  include/linux/fs.h          |  2 ++
>  kernel/sysctl.c             | 18 +++++++++++++
>  4 files changed, 114 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
> index 6c00c1e..819caf8 100644
> --- a/Documentation/sysctl/fs.txt
> +++ b/Documentation/sysctl/fs.txt
> @@ -34,7 +34,9 @@ Currently, these files are in /proc/sys/fs:
>  - overflowgid
>  - pipe-user-pages-hard
>  - pipe-user-pages-soft
> +- protected_fifos
>  - protected_hardlinks
> +- protected_regular
>  - protected_symlinks
>  - suid_dumpable
>  - super-max
> @@ -182,6 +184,24 @@ applied.
>
>  ==============================================================
>
> +protected_fifos:
> +
> +The intent of this protection is to avoid unintentional writes to
> +an attacker-controlled FIFO, where a program expected to create a regular
> +file.
> +
> +When set to "0", writing to FIFOs is unrestricted.
> +
> +When set to "1" don't allow O_CREAT open on FIFOs that we don't own
> +in world writable sticky directories, unless they are owned by the
> +owner of the directory.
> +
> +When set to "2" it also applies to group writable sticky directories.
> +
> +This protection is based on the restrictions in Openwall.
> +
> +==============================================================
> +
>  protected_hardlinks:
>
>  A long-standing class of security issues is the hardlink-based
> @@ -202,6 +222,22 @@ This protection is based on the restrictions in Openwall and grsecurity.
>
>  ==============================================================
>
> +protected_regular:
> +
> +This protection is similar to protected_fifos, but it
> +avoids writes to an attacker-controlled regular file, where a program
> +expected to create one.
> +
> +When set to "0", writing to regular files is unrestricted.
> +
> +When set to "1" don't allow O_CREAT open on regular files that we
> +don't own in world writable sticky directories, unless they are
> +owned by the owner of the directory.
> +
> +When set to "2" it also applies to group writable sticky directories.
> +
> +==============================================================
> +
>  protected_symlinks:
>
>  A long-standing class of security issues is the symlink-based
> diff --git a/fs/namei.c b/fs/namei.c
> index 921ae32..eaab668 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -883,6 +883,8 @@ static inline void put_link(struct nameidata *nd)
>
>  int sysctl_protected_symlinks __read_mostly = 0;
>  int sysctl_protected_hardlinks __read_mostly = 0;
> +int sysctl_protected_fifos __read_mostly;
> +int sysctl_protected_regular __read_mostly;
>
>  /**
>   * may_follow_link - Check symlink following for unsafe situations
> @@ -996,6 +998,54 @@ static int may_linkat(struct path *link)
>         return -EPERM;
>  }
>
> +/**
> + * may_create_in_sticky - Check whether an O_CREAT open in a sticky directory
> + *                       should be allowed, or not, on files that already
> + *                       exist.
> + * @dir: the sticky parent directory
> + * @name: the file name
> + * @inode: the inode of the file to open
> + *
> + * Block an O_CREAT open of a FIFO (or a regular file) when:
> + *   - sysctl_protected_fifos (or sysctl_protected_regular) is enabled
> + *   - the file already exists
> + *   - we are in a sticky directory
> + *   - we don't own the file
> + *   - the owner of the directory doesn't own the file
> + *   - the directory is world writable
> + * If the sysctl_protected_fifos (or sysctl_protected_regular) is set to 2
> + * the directory doesn't have to be world writable: being group writable will
> + * be enough.
> + *
> + * Returns 0 if the open is allowed, -ve on error.
> + */
> +static int may_create_in_sticky(struct dentry * const dir,
> +                               const unsigned char * const name,
> +                               struct inode * const inode)
> +{
> +       if ((!sysctl_protected_fifos && S_ISFIFO(inode->i_mode)) ||
> +           (!sysctl_protected_regular && S_ISREG(inode->i_mode)) ||
> +           likely(!(dir->d_inode->i_mode & S_ISVTX)) ||
> +           uid_eq(inode->i_uid, dir->d_inode->i_uid) ||
> +           uid_eq(current_fsuid(), inode->i_uid))
> +               return 0;
> +
> +       if (likely(dir->d_inode->i_mode & 0002) ||
> +           (dir->d_inode->i_mode & 0020 &&
> +            ((sysctl_protected_fifos >= 2 && S_ISFIFO(inode->i_mode)) ||
> +             (sysctl_protected_regular >= 2 && S_ISREG(inode->i_mode))))) {
> +               pr_notice_ratelimited("denied writing in '%s' of %u.%u in a sticky directory by UID %u, EUID %u, process %s:%d.\n",
> +                                     name,
> +                                     from_kuid(&init_user_ns, inode->i_uid),
> +                                     from_kgid(&init_user_ns, inode->i_gid),
> +                                     from_kuid(&init_user_ns, current_uid()),
> +                                     from_kuid(&init_user_ns, current_euid()),
> +                                     current->comm, current->pid);

Instead of this pr_notice_ratelimited(), I think
audit_log_link_denied() should be refactored and used instead. Drop
this line from this patch, and I think this is great as-is. The
logging can be separate (as it may get heavily bike-shed, as I
experienced with hard/symlink restrictions).

Otherwise, I think this looks great.

Acked-by: Kees Cook <keescook@...omium.org>

I'll create a branch for this on git.kernel.org and see if anything
surprising pops out. :)

-Kees

> +               return -EACCES;
> +       }
> +       return 0;
> +}
> +
>  static __always_inline
>  const char *get_link(struct nameidata *nd)
>  {
> @@ -3355,9 +3405,14 @@ static int do_last(struct nameidata *nd,
>         if (error)
>                 return error;
>         audit_inode(nd->name, nd->path.dentry, 0);
> -       error = -EISDIR;
> -       if ((open_flag & O_CREAT) && d_is_dir(nd->path.dentry))
> -               goto out;
> +       if (open_flag & O_CREAT) {
> +               error = -EISDIR;
> +               if (d_is_dir(nd->path.dentry))
> +                       goto out;
> +               error = may_create_in_sticky(dir, nd->last.name, inode);
> +               if (unlikely(error))
> +                       goto out;
> +       }
>         error = -ENOTDIR;
>         if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
>                 goto out;
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 2a81556..9bf4e5c 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -72,6 +72,8 @@
>  extern int leases_enable, lease_break_time;
>  extern int sysctl_protected_symlinks;
>  extern int sysctl_protected_hardlinks;
> +extern int sysctl_protected_fifos;
> +extern int sysctl_protected_regular;
>
>  typedef __kernel_rwf_t rwf_t;
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index f98f28c..295f528 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1794,6 +1794,24 @@ static int sysrq_sysctl_handler(struct ctl_table *table, int write,
>                 .extra2         = &one,
>         },
>         {
> +               .procname       = "protected_fifos",
> +               .data           = &sysctl_protected_fifos,
> +               .maxlen         = sizeof(int),
> +               .mode           = 0600,
> +               .proc_handler   = proc_dointvec_minmax,
> +               .extra1         = &zero,
> +               .extra2         = &two,
> +       },
> +       {
> +               .procname       = "protected_regular",
> +               .data           = &sysctl_protected_regular,
> +               .maxlen         = sizeof(int),
> +               .mode           = 0600,
> +               .proc_handler   = proc_dointvec_minmax,
> +               .extra1         = &zero,
> +               .extra2         = &two,
> +       },
> +       {
>                 .procname       = "suid_dumpable",
>                 .data           = &suid_dumpable,
>                 .maxlen         = sizeof(int),
> --
> 1.9.1
>



-- 
Kees Cook
Pixel Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.