linux-kernel - mount + pid namespacing broken ?

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

Message-ID: <CAKk_3s_P18a3ZUb835ysa-MS3c-_TBT20MVsJLvPrsYKETS_-w@mail.gmail.com>
Date:	Sat, 1 Jun 2013 23:47:37 +0200
From:	Frederic Riss <frederic.riss@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: mount + pid namespacing broken ?

Hello,

I had a little application making use of pid and mount namespaces to
isolate some processes on some machines. This all worked well on 3.7
boxes. A coworker upgraded his machine and noticed that things weren't
working anymore on 3.8. The symptom he noticed is that remounting
/proc inside the namespaced process broke the /proc of the original
namespace. (Remounting /proc is necessary for the pid namespace to be
really effective)

There is a simple way to reproduce the issue if you have a new enough
util-linux where the unshare utility accepts the --pid option. Try
that:

bash-4.2$ unshare --pid --mount
-bash-4.2$ sudo mount -t proc /proc /proc
[sudo] password for friss:
sudo: unable to send audit message: Operation not permitted
-bash-4.2$

[ The audit failure is already a sign of something going wrong more on
that bellow. ]
Then in another terminal running in the root namesapce:

bash-4.2$ ls -l /proc/self
ls: cannot read symbolic link /proc/self: No such file or directory
lrwxrwxrwx 1 root root 0 Jun  1 23:37 /proc/self

As you see, remounting /proc in the private namespace broke the root /proc...

Now the namespace isn't functional anyway even if /proc doesn't get remounted:

bash-4.2$ unshare --pid --mount
-bash-4.2$ id
uid=1001(friss) gid=1001(friss) groups=1001(friss),10(wheel)
-bash-4.2$ id
-bash: fork: Cannot allocate memory
-bash-4.2$

It's able to run one process, but every following invocation will
fail. I suppose the audit issue mentioned above is just another
symptom.

All of this was working fine on 3.7 kernels. I tried it on latest 3.8
and 3.9 and it fails on both. My application didn't make use of
unshare, but instead forked a new process with the namespacing flags.
The symptoms are identical in both cases.

Fred.
--
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/