Delivery-Date: Thu, 16 Oct 2014 05:48:47 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 651401E0314;
	Thu, 16 Oct 2014 05:48:46 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 092263101A;
	Thu, 16 Oct 2014 09:48:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C79CC304BC
 for <tor-talk@lists.torproject.org>; Thu, 16 Oct 2014 09:48:35 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VtG_VWkxNj4P for <tor-talk@lists.torproject.org>;
 Thu, 16 Oct 2014 09:48:35 +0000 (UTC)
Received: from turtles.fscked.org (turtles.fscked.org [76.73.17.194])
 by eugeni.torproject.org (Postfix) with ESMTP id A4D802F25D
 for <tor-talk@lists.torproject.org>; Thu, 16 Oct 2014 09:48:35 +0000 (UTC)
Date: Thu, 16 Oct 2014 02:48:26 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20141016094826.GD6668@torproject.org>
References: <542E5246.5070006@tengu.ch> <20141003222706.GF9509@torproject.org>
MIME-Version: 1.0
In-Reply-To: <20141003222706.GF9509@torproject.org>
Subject: Re: [tor-talk] orWall 1.0.0 released!
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5246752128810792248=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============5246752128810792248==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="KdquIMZPjGJQvRdI"
Content-Disposition: inline


--KdquIMZPjGJQvRdI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Mike Perry:
> CJ:
> > Hello!
> >=20
> > just a small update regarding orWall: it's released 1.0.0!
> > There's still *one* annoying issue regarding the tethering, but it
> > should be OK next week. Just have to take some time in order to debug
> > this for good.
>=20
> I also suggest soliciting input about the DNS issue we discussed where
> DNS queries are done by root on Android 4.3+ unless the
> 'ANDROID_DNS_MODE=3Dlocal' environment variable is set. Perhaps someone
> will come up with a clever hack to set this env var in a persistent way
> that we haven't thought of, or find some way to write a shim on the DNS
> resolution filesystem socket to enforce what we want.
>=20
> You could list this on a known issues or FAQ page, or in your bugtracker
> I guess. Making root/UID 0 handle DNS is also a security risk, and I'm
> very surprised the Android team thought this was a good idea. :/

I just noticed another issue this DNS-as-root snafu causes: The "Enable
Browser" option seems to leave the UID 0 DNS redirect rule in place,
which causes DNS lookups to fail if Tor is unreachable, which in turn
makes most captive portals unusable (since Tor can't be used to do the
DNS resolution for them).

I guess for now the only option is to remove the DNS redirect rule for
the duration that the "Enable Browser" option is active? Sucky, but
better than not being able to use captive portals..


--=20
Mike Perry

--KdquIMZPjGJQvRdI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUP5RqAAoJEEEC+JXS8eGG5MsP/0Z7sNb4lp797X4VhSFJMAxb
hiBNwzc0fZeZn9mwpIPchDd6S+f7wlWBTKyWQerb3TUn1gnA+BYiEs47TxRCMntj
oYuffb0C7EFhRqqPaLZzJK9KNTtmo+2+6vs67EPlSzctdHkKI+1LI9mm06mD/ZSU
8Ob/Rt8CkVYGPsPMR2qmtGbKmSo/YdFpJWa5NTuEFVY2IpKdtjJTH8fPmNkKcDHr
GbOpt2MD6Mnd7TD/Ffp1VQrmkCqxbFcLAgJl+eAiAQA7Jkd7CovsKxuI4E//lYiV
0pMLnkAL6caOF/VKl2lgn9Mzc+ebPF0TThLVuj9EmqmbaUMV/ZXA69E0IHhnEt/p
euLtuqsCl7VyaZfOrPBo57u9A1WP02XCm4jFehevxtllKR/DFUmfMDzI7DHU+0WJ
VITGBB6jzTol62y9j7XLtys32yYQqTpEqJqVATW5DvT3D3JCfITlFTdvJ3P3r2J8
fIg624CwC8CJ/Q0RGQ9J2tWyL8QmlXxTSPFHqbLAVBSkV/6biaNz55qTmhQuFtRW
hdUMu6WAJ5HsfAXujtxVtmOjhFBKM9XT0SZG62S6K3sjf0RFlwj8H2eQOhe1iu0I
sJhVjP8oZ0Z/4pXnjJ7uWnuB0N0XrA8J548zmg+g65ld7CgxsUjRdALDHq1FxCog
TJFzzy7UOTBhF4nSpHme
=jMLE
-----END PGP SIGNATURE-----

--KdquIMZPjGJQvRdI--

--===============5246752128810792248==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

--===============5246752128810792248==--

