linux-kernel - About namespaces and unshare() syscall.

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>] [day] [month] [year] [list]

Date:	Sun, 3 Mar 2013 19:06:29 -0300
From:	Raphael S Carvalho <raphael.scarv@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: About namespaces and unshare() syscall.

Hi Eric W. Biederman and Serge Hallyn,

I'm a newcomer to Linux kernel Development, and I really like the way
Linux manages namespaces.
By the way, I'm studying how copy_process() deals with it. I mean,
sharing namespaces by default and duplicating namespaces on demand.
I would appreciate if you can give me tips about where to get started
(Which areas are needing either help or improvement).

Regarding to unshare syscall, I really care about how the following
fragment of code will work in the future:
(kernel/fork.c) static int check_unshare_flags(unsigned long unshare_flags):
...
1735        if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM)) {
1736                /* FIXME: get_task_mm() increments ->mm_users */
1737                if (atomic_read(&current->mm->mm_users) > 1)
1738                        return -EINVAL;
1739        }

For example, suppose CLONE_VM was added to Unshare syscall, and so you
created an application which relies on this new feature (Unshare VM).
So I found your application in the Internet, but I'm running a kernel
which still has the above checking.

It won't work properly! why?
Taking a careful look at it, I realized that if one of those flags
were passed to the unshare syscall and the current process is sharing
its VM among other processes, the syscall would always return an
invalid error.

Conclusion: Your application (relying on Unshare CLONE_VM feature)
wouldn't work on previous kernel versions since the old
check_unshare_flags() was programmed so that CLONE_VM (with current
process sharing its VM) is implicitly an invalid operation. Thus,
lacking backward compatibility.

I also was reading why CLONE_VM was removed from Unshare syscall, it
seems a core dump could be processing at the same time, so bad things
might happen. However, it seems this feature will only be implemented
when really needed.

Regards,
Raphael S.Carvalho <raphael.scarv@...il.com>
--
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/