[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <A6FCC3DA-C72C-4B59-A27E-E91F85949608@vt.edu>
Date: Mon, 25 Mar 2019 13:33:51 -0400
From: TongZhang <ztong@...edu>
To: 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,
Stephen Smalley <sds@...ho.nsa.gov>,
Shen Wenbo <shenwenbosmile@...il.com>
Subject: Repost: Missing security_mmap_file() in remap_file_pages syscall
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<—————————————————————————————
Powered by blists - more mailing lists