linux-kernel - Re: Repost: Missing security_mmap_file() in remap_file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3fa343e7-5c22-5a97-cf4f-a9156a0696a7@tycho.nsa.gov>
Date:   Mon, 25 Mar 2019 15:53:34 -0400
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     TongZhang <ztong@...edu>, LKML <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org
Cc:     akpm@...ux-foundation.org, mhocko@...e.com,
        dan.j.williams@...el.com, rientjes@...gle.com, aarcange@...hat.com,
        dave@...olabs.net, kirill.shutemov@...ux.intel.com,
        Shen Wenbo <shenwenbosmile@...il.com>
Subject: Re: Repost: Missing security_mmap_file() in remap_file_pages syscall

On 3/25/19 1:33 PM, TongZhang wrote:
> Dear Kernel Developers,
> 
> We’d like to bring this up for a discussion again.
> 
> Several months ago we posted an email discussing a case where remap_file_pages() has no security_mmap_file() check.
> At that time we were told that do_mmap_pgoff() will base the new VMA permission on the old one.
> But somehow we still think the check is needed, for the reason that the advisory could first do a
> mmap() which can pass SELinux check then remap using a completely different file or region of file,
> which could possibly pose a risk.

I don't see an issue there. The incoming prot value from userspace is 
required to be zero (otherwise remap_file_pages returns -EINVAL), so the 
prot passed to do_mmap_pgoff() is entirely computed based on the 
existing vma flags.  The file is likewise obtained from the existing 
vma.  Any flags supplied by the caller other than MAP_NONBLOCK are 
ignored.  MAP_SHARED is always set in the flags passed to 
do_mmap_pgoff(), and the existing vma was required to have VM_SHARED set 
or remap_file_pages() would have returned -EINVAL.  If it spans more 
than one vma, their files and flags must match.  It appears that all of 
the inputs relevant to selinux_mmap_file() are necessarily the same as 
they would have been when creating the original vma.  The same appears 
to also be true for other security modules IIUC.

> 
> Thanks,
> - Tong
> 
> The original post is pasted below:
> 
> 8<—————————————————————————————
> [1.] One line summary of the problem:
> 
> Possible missing security_mmap_file() in remap_file_pages
> 
> [2.] Full description of the problem/report:
> 
> We noticed remap_file_pages syscall uses do_mmap_pgoff without LSM check: security_mmap_file().
> 
> This system call passed user controllable parameters to do_mmap_pgoff().
> 
> We think that this LSM check should be added in order to be consistent with other cases,
> for example:
> in system call mmap_pgoff(), shmat(), they all have security_mmap_file() check before calling
> do_mmap_pgoff().
> 
> [3.] Keywords: LSM check
> [4.] Kernel information
> [4.1] Kernel Version: 4.14.61
> 
> 8<—————————————————————————————
> 
> 
> 
> 
>