Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1287472

Re: [PATCH v4] fs: clear file privilege bits when mmap writing

From Jan Kara <jack@suse.cz>
Newsgroups linux.kernel
Subject Re: [PATCH v4] fs: clear file privilege bits when mmap writing
Date 2015-12-09 13:50 +0100
Message-ID <qDMlX-8sJ-7@gated-at.bofh.it> (permalink)
References <qDzRM-nl-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue 08-12-15 15:28:18, Kees Cook wrote:
> Normally, when a user can modify a file that has setuid or setgid bits,
> those bits are cleared when they are not the file owner or a member
> of the group. This is enforced when using write and truncate but not
> when writing to a shared mmap on the file. This could allow the file
> writer to gain privileges by changing a binary without losing the
> setuid/setgid/caps bits.
> 
> Changing the bits requires holding inode->i_mutex, so it cannot be done
> during the page fault (due to mmap_sem being held during the fault). We
> could do this during vm_mmap_pgoff, but that would need coverage in
> mprotect as well, but to check for MAP_SHARED, we'd need to hold mmap_sem
> again.
> 
> Instead, detect the need to clear the bits during the page fault, and
> actually remove the bits during final fput. Since the file was open for
> writing, it wouldn't have been possible to execute it yet.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> Here's another way? I wonder which of these will actually work. I
> wish we could reject writes if file_remove_privs() fails.

Yeah, the fact that we cannot do anything with file_remove_privs() failure
is rather unfortunate. So open for writing may be the best choice for
file_remove_privs() in the end? It's not perfect but it looks like the
least problematic solution.

Frankly writeable files that have SUID / SGID bits set are IMHO problems on
its own, with IMA attrs which are handled by file_remove_privs() as well
things may be somewhat different.

> diff --git a/fs/file_table.c b/fs/file_table.c
> index ad17e05ebf95..abb537ef4344 100644
> --- a/fs/file_table.c
> +++ b/fs/file_table.c
> @@ -191,6 +191,14 @@ static void __fput(struct file *file)
>  
>  	might_sleep();
>  
> +	/*
> +	 * XXX: While avoiding mmap_sem, we've already been written to.
> +	 * We must ignore the return value, since we can't reject the
> +	 * write.
> +	 */
> +	if (unlikely(file->f_remove_privs))
> +		file_remove_privs(file);
> +

You're missing i_mutex locking again ;).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
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/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v4] fs: clear file privilege bits when mmap writing Kees Cook <keescook@chromium.org> - 2015-12-09 00:30 +0100
  Re: [PATCH v4] fs: clear file privilege bits when mmap writing Jan Kara <jack@suse.cz> - 2015-12-09 13:50 +0100
    Re: [PATCH v4] fs: clear file privilege bits when mmap writing Kees Cook <keescook@chromium.org> - 2015-12-09 19:00 +0100

csiph-web