chroot and /proc/self

[palettentreter]

Hiho,
I'm running an amd64 2.6.28 hardened gentoo server with a chroot to compile software for client machines. Now in the chroot, javac keeps failing (for example when compiling xulrunner), because it can't find libjli.so. Turns out that in order to find that lib, it reads several files under /proc/self (because libjli.so is not installed in a standard path). Reproducing that error when running javac from the console seems to work only randomly, but once it did, strace showed that reading /proc/self returned ENOENT. So to me this looks like there's some problem with the /proc/self symlink in a hardened chroot. Looks like sometimes it isn't updated correctly and sometimes it doesn't even exist for a certain process. However this behaviour is only rarely seen when investigating from the console.
Has anyone heard of this? Any idea if this could be related to some sysctl or paxctl settings?

Oh and btw, now after trying for about the 5th time, compiling xulrunner magically worked. This really looks like a race condition or something. Thanks for any hints.

[spender]

Could you do two things for me:

Try with either the 2.6.31 or 2.6.32 patch on the grsecurity website. If those kernels still have the problem, please email me two strace logs at spender@grsecurity.net, one where the application works fine, and one where it cannot find /proc/self.

Thanks,
-Brad

[Grach]

Hmm, looks like the bug I faced before but slacked to report (sorry). It exist at least for a year, I think, and occurs under uncertain conditions inside the chroot, with and without enabled RBAC. Its impact can be more likely avoided by iterative stat(2)'ing of /proc within the chroot. It's relatively easy to trigger the bug during intensive compilation of multiple gentoo packages, for example, but what exactly triggers it - I don't know, strace gave me nothing but ENOENT (if I recall correctly) when accessig any file in /proc.

The bug was triggered both on /proc instances (mount -t proc proc /chroot/proc) and bind mounts of the system /proc (mount --bind /proc /chroot/proc). After bug occures, no process inside the chroot (not sure about not chrooted processes) can open(2) files inside /proc. I used 'while (sleep 0.5); do ls /proc > /dev/null; done &' inside the chroot as a workaround.

[spender]

Any file inside /proc? not even /proc/uptime?
And I assume disabling CONFIG_GRKERNSEC_CHROOT_FINDTASK makes the problem go away?

-Brad

[spender]

Can you try the following patch: http://grsecurity.net/~spender/chroot_proc.diff

It's against a 2.6.32.3 kernel patched with the latest version of grsecurity. I was able to briefly reproduce the issue earlier and am unable now with this patch applied. I want to confirm that it resolves the issue for you as well.

-Brad

[Grach]

Seems like fixed with the patch. At least I was unable to trigger the bug for more than a day. Thank you.

[palettentreter]

I've just upgraded to 2.6.31.11-grsec and the issue is still there. I'll try the 2.6.32 patch when I find the time. So long and great thanks so far...