[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 May 2018 19:30:47 +0200
From: Salvatore Mesoraca <s.mesoraca16@...il.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Akinobu Mita <akinobu.mita@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Arnd Bergmann <arnd@...db.de>, Davidlohr Bueso <dave@...olabs.net>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
2018-05-26 17:48 GMT+02:00 Alexey Dobriyan <adobriyan@...il.com>:
> On Sat, May 26, 2018 at 04:50:46PM +0200, Salvatore Mesoraca wrote:
>> Prevent a task from opening, in "write" mode, any /proc/*/mem
>> file that operates on the task's mm.
>> /proc/*/mem is mainly a debugging means and, as such, it shouldn't
>> be used by the inspected process itself.
>> Current implementation always allow a task to access its own
>> /proc/*/mem file.
>> A process can use it to overwrite read-only memory, making
>> pointless the use of security_file_mprotect() or other ways to
>> enforce RO memory.
>
> You can do it in security_ptrace_access_check()
No, because that hook is skipped when mm == current->mm:
https://elixir.bootlin.com/linux/v4.17-rc6/source/kernel/fork.c#L1111
> or security_file_open()
This is true, but it looks a bit overkill to me, especially since many of
the macros/functions used to handle proc's files won't be in scope
for an external LSM.
Is there any particular reason why you prefer it done via LSM?
Thank you,
Salvatore
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
