AS requires /proc in chroot jail to function

[GoogleCodeExporter]

What steps will reproduce the problem?

If one wishes to run an application live
with AS in a chroot jail, once is forced
to 'mount -o bind /proc' into the chroot
jail tree.

What is the expected output? What do you see instead?

AS complains loudly and kills the process
without access to /proc.

What version of the product are you using? On what operating system?

gcc 4.8.1

Please provide any additional information below.

While it is understandable that AS makes use
of /proc/self address-space map files, it would
be nice to be able to run a live AS instrumented
daemon in a chroot jail without having to expose
all of /proc and the associated attack-surface
therein.  Is not possible to 'mount -o bind'
just /proc/self since this is a dynamically
conjured symbolic link.

If there is no way that AS can function without
the process map information, perhaps it could
be cached during the pre-chroot phase of daemon
startup while /proc is still available?

Have found that AS runs as efficiently as
advertised and so it's desirable to run
live production daemons with it.

Original issue reported on code.google.com by starligh...@gmail.com on 31 Oct 2013 at 9:01

[GoogleCodeExporter]

Alex is playing with running asan under various sanboxes, so he may have some 
ideas.
But we do need /proc for various reasons.
We can not stop using it completely because it will cripple the tool.
We don't want to have two code paths (one when /proc exists and one when not)
because it will complicate the tool, which is already too complex for my taste.

We are open for suggestions. :) 

Original comment by konstant...@gmail.com on 31 Oct 2013 at 9:19

[GoogleCodeExporter]

Perhaps AS could, as an option, automatically

   mount -o bind /proc/<pid> /chroot/proc/<pid>

on detecting the 'chroot' call.  Or maybe
just open the /proc/<pid> directory
via the /proc/self auto-symlink at that
time, though this has the potential to
open a door to jail escape.  My thought
is to minimize how much of /proc is
exposed to a potential attacker.

In that same vein I find the new
kernel 'seccomp' BPF capability
enticing.  It's all about minimizing
attack surface.

Original comment by starligh...@gmail.com on 31 Oct 2013 at 10:00

[GoogleCodeExporter]

Because /proc is unavailable in Chrome's sandboxes, we cache the contents of 
/proc/self/maps (which generally don't change because no libraries are loaded 
once the sandbox is enabled).
Will that work for you?
The client program just needs to call __sanitizer_sandbox_on_notify(NULL) 
before chrooting to make ASan save the contents of /proc/self/maps

Original comment by ramosian.glider@gmail.com on 26 Dec 2013 at 3:22

[GoogleCodeExporter]

Excellent!  That works perfect.  Thank you very much!  Sorry for slow reply.

Original comment by starligh...@gmail.com on 3 Jan 2014 at 4:22

[GoogleCodeExporter]

Looks like there's no action needed on our side here.

Original comment by samso...@google.com on 16 Jan 2014 at 6:59

• Changed state: WontFix