Hi Cyrill,
On 3/23/21 10:06 PM, Cyrill Gorcunov wrote:
[..]
> --- linux-tip.git.orig/kernel/sys.c
> +++ linux-tip.git/kernel/sys.c
> @@ -1961,6 +1961,30 @@ out:
> return error;
> }
>
> +static int copy_auxv_from_user(unsigned long *auxv, size_t auxv_size,
> +
prctl(PR_SET_MM, PR_SET_MM_AUXV | PR_SET_MM_MAP, ...) copies user
provided auxiliary vector to kernel and saves it to mm::saved_auxv,
this involves same code in to places. Lets move it into one helper
instead.
When we copy data from user space we make sure that the vector ends
up with AT_NULL key
On Mon, Aug 25, 2014 at 02:08:43PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is cre
On Mon, Aug 25, 2014 at 02:08:43PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
> On 08/23, Cyrill Gorcunov wrote:
> >
> > On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > And btw, where do you see RLIMIT_STACK in do_shmat() ?
> >
> > Indirectly, though start_stack pointer. We assign it
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> >
> > And btw, where do you see RLIMIT_STACK in do_shmat() ?
>
> Indirectly, though start_stack pointer. We assign it in setup_arg_pages
> taking into
> account RLIMIT_STACK value, then do_shmat
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > Besides, it can't help anyway. cred_guard_mutex is per-process (not
> > > per-thread),
> > > suppose that a vfork()'ed child does prctl() while another thread reads
> > > the
> > > parent's /proc/pid/auxv.
> >
> > Then
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
> >
> > On 08/23, Oleg Nesterov wrote:
> > >
> > > On 08/23, Cyrill Gorcunov wrote:
> > >
> > > > Looks like I need
> > > > to use cred_guard_mutex instead of task_lock here, no?
> > >
> > > Please
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
> forgot to mention,
>
> On 08/23, Oleg Nesterov wrote:
> >
> > On 08/23, Cyrill Gorcunov wrote:
> >
> > > Looks like I need
> > > to use cred_guard_mutex instead of task_lock here, no?
> >
> > Please don't. First of all, it can't
forgot to mention,
On 08/23, Oleg Nesterov wrote:
>
> On 08/23, Cyrill Gorcunov wrote:
>
> > Looks like I need
> > to use cred_guard_mutex instead of task_lock here, no?
>
> Please don't. First of all, it can't help because proc_pid_auxv() doesn't hold
> this lock. It does mm_access() which drops
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
> > >
> > > It should protect from allocation/devetion/mergin of another vma. IOW when
> > > I lookup for vma I need to be sure it exist and won't disappear at least
> > > while I validate it.
> >
>
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
> >
> > It should protect from allocation/devetion/mergin of another vma. IOW when
> > I lookup for vma I need to be sure it exist and won't disappear at least
> > while I validate it.
>
> plus you need mmap_sem (at least for reading)
On 08/23, Cyrill Gorcunov wrote:
>
> On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
> > Hi Cyrill,
> >
> > I think the patch is fine but I can't understand the usage of mmap_sem
> > and alloc_lock,
> >
> > > + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
> >
> >
On 08/23, Cyrill Gorcunov wrote:
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma()
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
It should protect from allocation/devetion/mergin of another vma. IOW when
I lookup for vma I need to be sure it exist and won't disappear at least
while I validate it.
plus you need mmap_sem (at least for reading) when you
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
It should protect from allocation/devetion/mergin of another vma. IOW when
I lookup for vma I need to be sure it exist and won't disappear at least
while I validate it.
plus you need
forgot to mention,
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't help because proc_pid_auxv() doesn't hold
this lock. It does mm_access() which drops this lock
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
forgot to mention,
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't help because
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
Besides, it can't help anyway. cred_guard_mutex is per-process (not
per-thread),
suppose that a vfork()'ed child does prctl() while another thread reads
the
parent's /proc/pid/auxv.
Then either I need to use
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
And btw, where do you see RLIMIT_STACK in do_shmat() ?
Indirectly, though start_stack pointer. We assign it in setup_arg_pages
taking into
account RLIMIT_STACK value, then do_shmat operates
On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
And btw, where do you see RLIMIT_STACK in do_shmat() ?
Indirectly, though start_stack pointer. We assign it in
On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
> On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov wrote:
>
> > >
> > > Or will we? What happens if we later decide that some additional field
> > > needs to be added? Do we version the interface? Add a new prctl()
> > > mode?
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov wrote:
> >
> > Or will we? What happens if we later decide that some additional field
> > needs to be added? Do we version the interface? Add a new prctl()
> > mode? Let's cook up a plan for that and at least add to changelog?
>
> I don't
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
> > >
> > > But it's a bit hacky. Can anyone think of anything smarter?
> >
> > Looks good to me and not that hacky actually.
>
> Hacky :( I guess it's pretty safe because this is a userspace-visible
> structure so we'll never be
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
> Hi Cyrill,
>
> I think the patch is fine but I can't understand the usage of mmap_sem
> and alloc_lock,
>
> > + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
>
> OK, find_vma() needs mmap_sem. But otherwise,
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
> + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this should be called
under down_read(>mmap_sem) ? What this lock tries to
On Fri, 22 Aug 2014 10:32:42 +0400 Cyrill Gorcunov wrote:
> > > + 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 |=
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 --
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,
On Fri, 22 Aug 2014 10:32:42 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
+ 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 |=
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this should be called
under down_read(mm-mmap_sem) ? What this lock tries to
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
But it's a bit hacky. Can anyone think of anything smarter?
Looks good to me and not that hacky actually.
Hacky :( I guess it's pretty safe because this is a userspace-visible
structure so we'll never be changing it.
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Or will we? What happens if we later decide that some additional field
needs to be added? Do we version the interface? Add a new prctl()
mode? Let's cook up a plan for that and at least add to changelog?
On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Or will we? What happens if we later decide that some additional field
needs to be added? Do we version the interface? Add a new prctl()
On Mon, 04 Aug 2014 21:22:59 +0400 Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is cre
On Mon, 04 Aug 2014 21:22:59 +0400 Cyrill Gorcunov gorcu...@openvz.org wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
> >
> > Signed-off-by: Cyrill Gorcunov
> > Cc: Kees Cook
> > Cc: Tejun Heo
> > Cc: Andrew Morton
> > Cc: Andrew Vagin
>
> Acked-by: Andrew Vagin
>
> I have tested this patch with criu. Everything work as expected.
Thanks
On Mon, Aug 04, 2014 at 09:22:59PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is cre
On Mon, Aug 04, 2014 at 09:22:59PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava...@openvz.org
Acked-by: Andrew Vagin
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is created capable(CAP_SYS_RESOURC
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
> Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
> it out of and rename the helper to prctl_set_mm_exe_file_locked.
> This will allow to reuse this function in a next patch.
>
> Signed-off-by: Cyrill Gorcunov
> Cc: Kees Cook
> Cc:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W.
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer
On Thu, Jul 24, 2014 at 12:31:54PM -0700, Kees Cook wrote:
...
> > +
> > +#ifdef CONFIG_STACK_GROWSUP
> > + if (may_adjust_brk(rlimit(RLIMIT_STACK),
> > + stack_vma->vm_end,
> > + prctl_map->start_stack, 0, 0))
> > +#else
> > + if
On Thu, Jul 24, 2014 at 9:47 AM, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call, in particular once new user namespace
> is created capable(CAP_
On Thu, Jul 24, 2014 at 11:44:50AM -0700, Kees Cook wrote:
...
> >
> > The file can have a suid bit, so after executing it we may lose ability
> > to attach to it. To check that we can check that uid and gid is zero
> > in a current userns (local root).
> >
> > What else do we need to check?
>
>
On Thu, Jul 24, 2014 at 6:48 AM, Andrew Vagin wrote:
> On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
>> > - @exe_fd is referred from /proc/$pid/exe and when generating
>> >coredump. We uses prctl_set_mm_exe_file_locked helper to update
>> >this member, so exe-file link
Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W.
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
On Thu, Jul 24, 2014 at 05:48:28PM +0400, Andrew Vagin wrote:
> On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> > > - @exe_fd is referred from /proc/$pid/exe and when generating
> > >coredump. We uses prctl_set_mm_exe_file_locked helper to update
> > >this member, so exe-file
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> > - @exe_fd is referred from /proc/$pid/exe and when generating
> >coredump. We uses prctl_set_mm_exe_file_locked helper to update
> >this member, so exe-file link modification remains one-shot
> >action.
>
> Controlling
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
- @exe_fd is referred from /proc/$pid/exe and when generating
coredump. We uses prctl_set_mm_exe_file_locked helper to update
this member, so exe-file link modification remains one-shot
action.
Controlling exe_fd
On Thu, Jul 24, 2014 at 05:48:28PM +0400, Andrew Vagin wrote:
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
- @exe_fd is referred from /proc/$pid/exe and when generating
coredump. We uses prctl_set_mm_exe_file_locked helper to update
this member, so exe-file link
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable(CAP_SYS_RESOURCE) no longer passes.
A approach is to eliminate CAP_SYS_RESOURCE
On Thu, Jul 24, 2014 at 6:48 AM, Andrew Vagin ava...@parallels.com wrote:
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
- @exe_fd is referred from /proc/$pid/exe and when generating
coredump. We uses prctl_set_mm_exe_file_locked helper to update
this member, so exe-file
On Thu, Jul 24, 2014 at 11:44:50AM -0700, Kees Cook wrote:
...
The file can have a suid bit, so after executing it we may lose ability
to attach to it. To check that we can check that uid and gid is zero
in a current userns (local root).
What else do we need to check?
Yeah, I think
On Thu, Jul 24, 2014 at 9:47 AM, Cyrill Gorcunov gorcu...@openvz.org wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
is created capable
On Thu, Jul 24, 2014 at 12:31:54PM -0700, Kees Cook wrote:
...
+
+#ifdef CONFIG_STACK_GROWSUP
+ if (may_adjust_brk(rlimit(RLIMIT_STACK),
+ stack_vma-vm_end,
+ prctl_map-start_stack, 0, 0))
+#else
+ if
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> On Fri, Jul 11, 2014 at 10:36 AM, Cyrill Gorcunov wrote:
> > On Wed, Jul 09, 2014 at 07:06:04PM +0400, Cyrill Gorcunov wrote:
> >>
> >> Thanks a lot for comments, Kees! I tend to agre, leaving off the @prctl_map
> >> variable out of
k better.
> ---
> From: Cyrill Gorcunov
> Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v2
>
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call
Gorcunov gorcu...@openvz.org
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v2
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call, in particular once new user namespace
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
On Fri, Jul 11, 2014 at 10:36 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, Jul 09, 2014 at 07:06:04PM +0400, Cyrill Gorcunov wrote:
Thanks a lot for comments, Kees! I tend to agre, leaving off the @prctl_map
variable out
ng something
> in security aspects when time permits.
I suppse this one should look better.
---
From: Cyrill Gorcunov
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v2
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem wi
in security aspects when time permits.
I suppse this one should look better.
---
From: Cyrill Gorcunov gorcu...@openvz.org
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation, v2
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem
On Wed, Jul 09, 2014 at 07:53:10AM -0700, Kees Cook wrote:
...
> > +
> > + /*
> > +* Make sure the pairs are ordered.
> > +*/
> > +#define __prctl_check_order(__map, __m1, __m2)
> > \
> > + (unsigned long)__map->__m2 <= (unsigned
comment since original "It takes
>> a pointer of prctl_mm_map structure which carries all members to be
>> updated" is too short.
>
> Here is a way more descriptove changelog I hope. Please poke me if
> more details needed, or something should be improved/changed and
>
" is too short.
Here is a way more descriptove changelog I hope. Please poke me if
more details needed, or something should be improved/changed and
etc.
---
From: Cyrill Gorcunov
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation
During development of c/r we've noticed that in ca
, or something should be improved/changed and
etc.
---
From: Cyrill Gorcunov gorcu...@openvz.org
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM
descriptove changelog I hope. Please poke me if
more details needed, or something should be improved/changed and
etc.
---
From: Cyrill Gorcunov gorcu...@openvz.org
Subject: prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation
During development of c/r we've noticed that in case if we need
On Wed, Jul 09, 2014 at 07:53:10AM -0700, Kees Cook wrote:
...
+
+ /*
+* Make sure the pairs are ordered.
+*/
+#define __prctl_check_order(__map, __m1, __m2)
\
+ (unsigned long)__map-__m2 = (unsigned long)__map-__m1
+
On Tue, Jul 08, 2014 at 02:38:30PM -0700, Andrew Morton wrote:
> On Tue, 8 Jul 2014 23:08:49 +0400 Cyrill Gorcunov wrote:
>
> > Ping. Guys, any commens please?
>
> Well, allowing a process to modify pretty deep internals like this is
> always scary from a security point of view, and now we're
On Tue, 8 Jul 2014 23:08:49 +0400 Cyrill Gorcunov wrote:
> Ping. Guys, any commens please?
Well, allowing a process to modify pretty deep internals like this is
always scary from a security point of view, and now we're removing
CAP_SYS_RESOURCE protections. Yikes. Convince me we aren't
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call.
>
> Current PR_SET_MM code forbids t
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call.
Current PR_SET_MM code forbids to modify fields
On Tue, 8 Jul 2014 23:08:49 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Ping. Guys, any commens please?
Well, allowing a process to modify pretty deep internals like this is
always scary from a security point of view, and now we're removing
CAP_SYS_RESOURCE protections. Yikes. Convince me
On Tue, Jul 08, 2014 at 02:38:30PM -0700, Andrew Morton wrote:
On Tue, 8 Jul 2014 23:08:49 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Ping. Guys, any commens please?
Well, allowing a process to modify pretty deep internals like this is
always scary from a security point of view, and
On Fri, Jul 04, 2014 at 11:52:56AM +0400, Andrew Vagin wrote:
> > +
> > +struct prctl_mm_map {
> > + unsigned long start_code;
>
> "unsigned long" has different sizes on x86_64 and x86, so a compat
> is required for x32 processes on x64 kernel.
Yes, good point. I think we can use u64/32
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call.
>
> Current PR_SET_MM code forbids t
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call.
Current PR_SET_MM code forbids to modify fields
On Fri, Jul 04, 2014 at 11:52:56AM +0400, Andrew Vagin wrote:
+
+struct prctl_mm_map {
+ unsigned long start_code;
unsigned long has different sizes on x86_64 and x86, so a compat
is required for x32 processes on x64 kernel.
Yes, good point. I think we can use u64/32 types instead
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
> During development of c/r we've noticed that in case if we need to
> support user namespaces we face a problem with capabilities in
> prctl(PR_SET_MM, ...) call.
Sigh, I updated changelog after I started writting the 0/
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call.
Current PR_SET_MM code forbids to modify fields if no CAP_SYS_RESOURCE
granted, but rather relies on one who use this interface is passing
Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W.
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call.
Current PR_SET_MM code forbids to modify fields if no CAP_SYS_RESOURCE
granted, but rather relies on one who use this interface is passing
On Thu, Jul 03, 2014 at 06:33:20PM +0400, Cyrill Gorcunov wrote:
During development of c/r we've noticed that in case if we need to
support user namespaces we face a problem with capabilities in
prctl(PR_SET_MM, ...) call.
Sigh, I updated changelog after I started writting the 0/0 message
al file-systems.
The code that does that was already included in the Linux kernel by
the CRIU group, in the form of "prctl(PR_SET_MM)", but prior to this
was enclosed within their private "#ifdef CONFIG_CHECKPOINT_RESTORE",
which is normally disabled.
It was not clear from you
al file-systems.
The code that does that was already included in the Linux kernel by
the CRIU group, in the form of "prctl(PR_SET_MM)", but prior to this
was enclosed within their private "#ifdef CONFIG_CHECKPOINT_RESTORE",
which is normally disabled.
It was not clear from you
-systems.
The code that does that was already included in the Linux kernel by
the CRIU group, in the form of prctl(PR_SET_MM), but prior to this
was enclosed within their private #ifdef CONFIG_CHECKPOINT_RESTORE,
which is normally disabled.
It was not clear from your answer, Andrew, whether you
-systems.
The code that does that was already included in the Linux kernel by
the CRIU group, in the form of prctl(PR_SET_MM), but prior to this
was enclosed within their private #ifdef CONFIG_CHECKPOINT_RESTORE,
which is normally disabled.
It was not clear from your answer, Andrew, whether you
1 - 100 of 136 matches
Mail list logo
