All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.