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 <keesc...@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 <j...@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
