linux-kernel - Re: [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140822063242.GI14072@moon>
Date:	Fri, 22 Aug 2014 10:32:42 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, keescook@...omium.org, tj@...nel.org,
	avagin@...nvz.org, ebiederm@...ssion.com, hpa@...or.com,
	serge.hallyn@...onical.com, xemul@...allels.com,
	segoon@...nwall.com, kamezawa.hiroyu@...fujitsu.com,
	mtk.manpages@...il.com, jln@...gle.com
Subject: Re: [patch 4/4] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP
 operation, v3

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/