* Repost: Missing security_mmap_file() in remap_file_pages syscall
@ 2019-03-25 17:33 TongZhang
2019-03-25 17:47 ` Kirill A. Shutemov
2019-03-25 19:53 ` Stephen Smalley
0 siblings, 2 replies; 3+ messages in thread
From: TongZhang @ 2019-03-25 17:33 UTC (permalink / raw)
To: LKML, linux-security-module
Cc: akpm, mhocko, dan.j.williams, rientjes, aarcange, dave,
kirill.shutemov, Stephen Smalley, Shen Wenbo
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.
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<—————————————————————————————
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Repost: Missing security_mmap_file() in remap_file_pages syscall
2019-03-25 17:33 Repost: Missing security_mmap_file() in remap_file_pages syscall TongZhang
@ 2019-03-25 17:47 ` Kirill A. Shutemov
2019-03-25 19:53 ` Stephen Smalley
1 sibling, 0 replies; 3+ messages in thread
From: Kirill A. Shutemov @ 2019-03-25 17:47 UTC (permalink / raw)
To: TongZhang
Cc: LKML, linux-security-module, akpm, mhocko, dan.j.williams,
rientjes, aarcange, dave, kirill.shutemov, Stephen Smalley,
Shen Wenbo
On Mon, Mar 25, 2019 at 01:33:51PM -0400, 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.
Could you elabarote on the risk you see? A bad scenario that could be
prevented with SELinux check would be helpful.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Repost: Missing security_mmap_file() in remap_file_pages syscall
2019-03-25 17:33 Repost: Missing security_mmap_file() in remap_file_pages syscall TongZhang
2019-03-25 17:47 ` Kirill A. Shutemov
@ 2019-03-25 19:53 ` Stephen Smalley
1 sibling, 0 replies; 3+ messages in thread
From: Stephen Smalley @ 2019-03-25 19:53 UTC (permalink / raw)
To: TongZhang, LKML, linux-security-module
Cc: akpm, mhocko, dan.j.williams, rientjes, aarcange, dave,
kirill.shutemov, Shen Wenbo
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<—————————————————————————————
>
>
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-03-25 20:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-25 17:33 Repost: Missing security_mmap_file() in remap_file_pages syscall TongZhang
2019-03-25 17:47 ` Kirill A. Shutemov
2019-03-25 19:53 ` Stephen Smalley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).