public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, keescook@chromium.org,
	tj@kernel.org, avagin@openvz.org, ebiederm@xmission.com,
	hpa@zytor.com, serge.hallyn@canonical.com, xemul@parallels.com,
	segoon@openwall.com, kamezawa.hiroyu@jp.fujitsu.com,
	mtk.manpages@gmail.com, jln@google.com
Subject: Re: [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3
Date: Fri, 22 Aug 2014 10:32:42 +0400	[thread overview]
Message-ID: <20140822063242.GI14072@moon> (raw)
In-Reply-To: <20140821155115.8433bb37bf631b8ae8340f84@linux-foundation.org>

On Thu, Aug 21, 2014 at 03:51:15PM -0700, Andrew Morton wrote:
...
> > 
> > Still note that updating exe-file link now doesn't require sys-resource
> > capability anymore, after all there is no much profit in preventing setup
> > own file link (there are a number of ways to execute own code -- ptrace,
> > ld-preload, so that the only reliable way to find which exactly code
> > is executed is to inspect running program memory). Still we require
> > the caller to be at least user-namespace root user.
> > 
> > I believe the old interface should be deprecated and ripped off
> > in a couple of kernel releases if no one against.
> > 
> > To test if new interface is implemented in the kernel one
> > can pass PR_SET_MM_MAP_SIZE opcode and the kernel returns
> > the size of currently supported struct prctl_mm_map.
> 
> Please convince me that we're not adding any security holes.

I've commented all the fields and their purpose and triple-checked them all,
so I don't see any sec. problems, but for same purpose I've CC'ed a number
of people just to be on safe side. Again, if we want this feature to be
somehow more controlled -- we can add some sysctl variable which would
enable/disable this interface globally.

> > +	error |= __prctl_check_addr_space(start_code);
> > +	error |= __prctl_check_addr_space(end_code);
> > +	error |= __prctl_check_addr_space(start_data);
> > +	error |= __prctl_check_addr_space(end_data);
> > +	error |= __prctl_check_addr_space(start_stack);
> > +	error |= __prctl_check_addr_space(start_brk);
> > +	error |= __prctl_check_addr_space(brk);
> > +	error |= __prctl_check_addr_space(arg_start);
> > +	error |= __prctl_check_addr_space(arg_end);
> > +	error |= __prctl_check_addr_space(env_start);
> > +	error |= __prctl_check_addr_space(env_end);
> 
> Boy this is verbose.  I had a little fiddle and came up with
...
> 
> +
> +		for (i = 0; i < ARRAY_SIZE(offsets); i++) {
> +			u64 val = ((u64 *)prctl_map)[offsets[i]];
> +
> +			if (val < mmap_min_addr || val >= mmap_max_addr) {
> +				error = -EINVAL;
> +				goto out;
> +			}
> +		}
> +	}
> 
> and it saved 400 bytes of text.
> 
> But it's a bit hacky.  Can anyone think of anything smarter?

Looks good to me and not that hacky actually. Should I update on top
for -mm tree?

  reply	other threads:[~2014-08-22  6:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04 17:22 [patch 0/4] prctl: set-mm -- Rework interface, v3 Cyrill Gorcunov
2014-08-04 17:22 ` [patch 1/4] mm: Introduce check_data_rlimit helper, v2 Cyrill Gorcunov
2014-08-04 20:25   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 2/4] mm: Use may_adjust_brk helper Cyrill Gorcunov
2014-08-04 20:25   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 3/4] prctl: PR_SET_MM -- Factor out mmap_sem when update mm::exe_file Cyrill Gorcunov
2014-08-04 20:22   ` Serge E. Hallyn
2014-08-04 17:22 ` [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v3 Cyrill Gorcunov
2014-08-04 21:01   ` Serge E. Hallyn
2014-08-05  8:08   ` Andrew Vagin
2014-08-05  8:12     ` Cyrill Gorcunov
2014-08-21 22:51   ` Andrew Morton
2014-08-22  6:32     ` Cyrill Gorcunov [this message]
2014-08-22  6:49       ` Andrew Morton
2014-08-22 20:38         ` Cyrill Gorcunov
2014-08-22 20:46           ` Andrew Morton
2014-08-22 21:13             ` Cyrill Gorcunov
2014-08-15 19:11 ` [patch 0/4] prctl: set-mm -- Rework interface, v3 Cyrill Gorcunov

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=20140822063242.GI14072@moon \
    --to=gorcunov@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jln@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=segoon@openwall.com \
    --cc=serge.hallyn@canonical.com \
    --cc=tj@kernel.org \
    --cc=xemul@parallels.com \
    /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