Newer versions of 'openssl' require access to
/proc/sys/kernel/random
and so the line
/proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random auto bind 0 0
must be added to the
/etc/fstab
file or the command
mount -o bind /proc/sys/kernel/random /chroot_tor/proc/sys/kernel/random
must be run from somewhere. Keep in mind that issuing the 'mount' more than once causes nested overly mounts rather than doing nothing, so the 'fstab' approach is best.
Obviously the directories
proc/sys/kernel/random
must be created in the 'chroot' jail tree.
----------------
This problem will appear when 'tor' attempts to roll-over it's key after several days. Took significant effort of figure out what happened as 'tor' dies without comment.
It appears that if 'tor' fails in the middle of a re-key operation, the node name and state is lost entirely and the relay must rebuild it's reputation from scratch with a new name. Quite vexing.
At 23:13 10/16/2013 -0400, starlight.2013q4@binnacle.cx wrote:
Newer versions of 'openssl' require access to
With the assistance of 'strings' it was determined that it is
/usr/local/lib64/libevent-2.0.so.5.1.9
that is actually responsible for accessing
/proc/sys/kernel/random/uuid
during rekey operations. openssl-1.0.1e does not appear to access this file.
At 23:13 10/16/2013 -0400, starlight.2013q4@binnacle.cx wrote:
Newer versions of 'openssl' require access to
/proc/sys/kernel/random
Got this wrong, in part due to the difficulty of debugging 'chroot'.
'libevent' does make use of /proc/sys/kernel/random/uuid if it's available but tolerates a failed open() and uses /dev/urandom in any case. Saw it in 'strace' and mistook this for the problem.
What was missing was
libgcc_s.so.1
which is documented as needed for CentOS but with no specific comment as to why. 'libgcc' is used by 'libpthreads' but is not kept loaded. Is dynamically loaded when 'pthread_exit()' is called during 'tor' reload operations and then unloaded. A way to test this is to SIGHUP 'tor'.
So a minimalist does not see 'libgcc' in the 'lsof' for 'tor', which starts fine without it, and thinks it unnecessary. What's painful is the week-long interval before 'tor' crashes with SIGABORT.
The error written to stderr
libgcc_s.so.1 must be installed for pthread_cancel to work
is lost since fd 2 goes to /dev/null by default when 'tor' runs as a daemon.
Suggest a comment about this be added to the 'chroot' documentation page, including that it's a good idea to test the 'chroot' setup with a
pkill -HUP tor
I think that Tor should implement natively support for self-chrooting and that those kind of approach are dirty, unmaintainable, hacks.
Most security software does support chrooting natively, simply by opening the relevant filesystem filedescriptor before chrooting, and then operating over it from inside the chroot.
On 13-10-18 03:34 AM, Fabio Pietrosanti (naif) wrote:
I think that Tor should implement natively support for self-chrooting and that those kind of approach are dirty, unmaintainable, hacks.
Most security software does support chrooting natively, simply by opening the relevant filesystem filedescriptor before chrooting, and then operating over it from inside the chroot.
Have you reviewed the patch attached to: https://trac.torproject.org/projects/tor/ticket/3794 The above may not be about "native" chroot, but this looks like it is at least partly: https://trac.torproject.org/projects/tor/ticket/7005 Perhaps open another enhancement ticket to tie it all together.
Problem: does "chroot" mean anything in a Windows environment?
On Fri, 2013-10-18 at 08:29 -0400, krishna e bera wrote:
Problem: does "chroot" mean anything in a Windows environment?
There is no real chroot solution on windows that I know of. What exist is an application virtualisation (which of course has other targets) but I would say that it also includes something like a chroot.
But that is nothing that is handled by a manufacturer - it is something that is only used in companies right now and the main target is the streaming of applications to target systems (At least that is what we use it for).
The important fact inside: The software does not need to do anything. The person who builds the "package" decides about the details e.g. what is the application allowed to access.
This is my personal view on windows - be aware that I might have missed something.
With kind regards,
Konrad
tor-relays@lists.torproject.org
-
Fabio Pietrosanti (naif) -
Konrad Neitzel -
krishna e bera -
starlight.2013q4＠binnacle.cx