linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>, Igor Stoppa <igor.stoppa@huawei.com>
Cc: willy@infradead.org, keescook@chromium.org, mhocko@kernel.org,
	david@fromorbit.com, rppt@linux.vnet.ibm.com, labbott@redhat.com,
	linux-security-module@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com
Subject: Re: [RFC PATCH v21 0/6] mm: security: ro protection for dynamic data
Date: Fri, 30 Mar 2018 00:25:22 +0400	[thread overview]
Message-ID: <5b2a6d5d-5e33-614b-c362-c02a99509def@gmail.com> (raw)
In-Reply-To: <20180327105509.62ec0d4d@lwn.net>

On 27/03/18 20:55, Jonathan Corbet wrote:
> On Tue, 27 Mar 2018 18:37:36 +0300
> Igor Stoppa <igor.stoppa@huawei.com> wrote:
> 
>> This patch-set introduces the possibility of protecting memory that has
>> been allocated dynamically.
> 
> One thing that jumps out at me as I look at the patch set is: you do not
> include any users of this functionality.  Where do you expect this
> allocator to be used?  Actually seeing the API in action would be a useful
> addition, I think.

Yes, this is very true.
Initially I had in mind to use LSM hooks as easy example, but sadly they 
seem to be in an almost constant flux.

My real use case is to secure both those and the SELinux policy DB.
I have said this few times, but it didn't seem to be worth mentioning in 
the cover letter.

I was hoping to get this merged and then attack both LSM and SELinux, 
but it didn't fly, so few months ago i decided to try it all together 
and put on hold my efforts to get pmalloc merged.

However, in January, happened this:
http://www.openwall.com/lists/kernel-hardening/2018/01/24/1

which rekindled my hopes to get pmalloc in first, as it would make my 
life easier in proposing the changes to SELinux, if they ar ebased on a 
nAPI that is already merged.

So I hope that, once both API and implementation for pmalloc are in good 
shape, xfs could be the first customer.

If that doesn't happen, I'll go back to the initial plan. Or look for 
some other easier target.

Also the IMA policy could benefit from pmalloc protection, I think, I 
spent about a week hacking on it and it seems feasible.
But it's not exactly small either.

I do not know if I should have followed some other path, but I'm having 
a bit of a hard time, since the API is objectively touching core 
functionality, and the change I'd like to use as example affects such a 
large component a SELinux.

--
igor

  reply	other threads:[~2018-03-29 20:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 15:37 Igor Stoppa
2018-03-27 15:37 ` [PATCH 1/6] struct page: add field for vm_struct Igor Stoppa
2018-03-27 15:37 ` [PATCH 2/6] vmalloc: rename llist field in vmap_area Igor Stoppa
2018-03-27 15:37 ` [PATCH 3/6] Protectable Memory Igor Stoppa
2018-03-27 15:37 ` [PATCH 4/6] Pmalloc selftest Igor Stoppa
2018-03-27 15:37 ` [PATCH 5/6] lkdtm: crash on overwriting protected pmalloc var Igor Stoppa
2018-03-27 15:37 ` [PATCH 6/6] Documentation for Pmalloc Igor Stoppa
2018-03-27 16:55 ` [RFC PATCH v21 0/6] mm: security: ro protection for dynamic data Jonathan Corbet
2018-03-29 20:25   ` Igor Stoppa [this message]
2018-03-29 20:50     ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b2a6d5d-5e33-614b-c362-c02a99509def@gmail.com \
    --to=igor.stoppa@gmail.com \
    --cc=corbet@lwn.net \
    --cc=david@fromorbit.com \
    --cc=igor.stoppa@huawei.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox