[Tails-dev] [review'n'merge 1.1.1] I2P boot parameter, fire…

このメッセージを削除

このメッセージに返信
著者: Kill Your TV
日付:  
To: tails-dev
新しいトピック: [Tails-dev] Simplifying the UX for I2P [Was: [review'n'merge 1.1.1] I2P boot parameter, firewall rules, etc.]
題目: [Tails-dev] [review'n'merge 1.1.1] I2P boot parameter, firewall rules, etc. (Was: What to do about I2P in Tails?)
All,

On Sun, 27 Jul 2014 10:02:18 +0000 (UTC)
intrigeri <intrigeri@???> wrote:

> > On 7/26/14, sajolida@??? <sajolida@???> wrote:
> >> Regarding the "when", if we decide to do a first temporary step by
> >> having an "i2p" boot option instead of an option in the Greeter,
> >> then we don't have to wait for the new Greeter... It feels a bit
> >> like going backward regarding our plans on the Greeter but we've
> >> been doing that for truecrypt forever and the doc is ready...
>
> Agreed, this looks like a good short-term plan, thanks!



> [...]
>
> Yes. I think all it takes is adapting the doc + writing a live-config
> hook that adds enable the needed credentials in sudoers, and makes the
> I2P launcher visible. Anyone willing to give it a try? I'd be happy to
> provide guidance and advice.


Done.

> Jacob Appelbaum wrote (27 Jul 2014 01:57:23 GMT) :
> > I wonder though if that also means that the firewall would be locked
> > down by default?
>
> I'm still not convince this buys us much (escalating privs to a user
> that has no running service, in order to benefit from its special
> firewall exceptions, doesn't seem so easy), *but*: if someone does the
> additional work, and if the changes are not too risky and invasive for
> a point-release, then it does seem possible, yes :)


Also done. Whether my proposed changes are too risky and invasive for a
point release someone else will have to decide, but I think it should
be fine.

Much longer version below:

The consensus has been that that it would be good to require a user to
explicitly acknowledge that they want access to I2P in order for it to
be easily accessible within the system. From what I understand, having
it as an option in the greeter isn't possible until the new greeter is
available. Therefore, I implemented the boot option. At the same time I
tightened up the firewall rules. These changes are available in

       http://repo.or.cz/w/tails/kytv.git feature/i2p-bootparam


and attached to this email in the form of four patches. The changes in
this branch (currently) apply cleanly to the stable & devel branches.

With these changes, after booting Tails without any particular options
specified at the boot prompt, I2P will not visible in the interface and
the I2P rules granting access will not be applied. That is, when "i2p"
is not given at the boot prompt:

  - the I2P binaries will not be accessible from the normal location
    at /usr/share/i2p 
  - the entry will not be visible in the Internet/Network menu.
  - the rules granting the i2psvc user access are not activated
  - new rules which DENY i2psvc from accessing the LAN are applied. As
    noted above, these DENY rules will be applied whether or not the
    "i2p" boot parameter is given


If the string "i2p" is added to the boot prompt:
  - the I2P menu entry returns
  - the installation directory /usr/share/i2p returns
  - the firewall rules which grant the i2psvc user access to the
    internet are enabled. 
  - the rules that allow the amnesia user to access the I2P
    services are enabled. 
  - a few whitelisted ports for the i2psvc user are opened on the
    loopback device:
    + the TorDNS ports
    + control ports used by the Tanuki Java Service Wrapper, which is
      in turn used by I2P
    + the ports for the I2P services


Other changes: 
  - plugins will be disabled within I2P. Plugins, without persistence
    aren't very useful. Now that I know the switch to disable them,
    let's do it. (Users that want to use them can easily enable them)
  - documentation updates (more to come, but maybe not for these
    changes?)
  - the webmail app is changed to keep emails on the mail server.
    The default setting was changed upstream to store emails
    locally.(I'm submitting this one since it's low risk for Tails and
    it greatly improves user experience/expectations). This change
    depends on I2P 0.9.14 or newer. A point release (0.9.14.1) should
    be ready a few days before the Tails freeze.


If these changes are acceptable, please consider them for inclusion in
the upcoming 1.1.1 release. Is there anything else that is desirable
with respect to I2P & 1.1.1?

(I presume that the separate browser will be too much for a point
release, but I'm going to start on that next for (potential) inclusion
in 1.2.)


--
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A
From abd3db5d457ea75d696bfb681c7a50dfd5e80a9a Mon Sep 17 00:00:00 2001
From: Kill Your TV <killyourtv@???>
Date: Sun, 27 Jul 2014 19:38:42 +0000
Subject: [PATCH 1/4] Add an I2P boot parameter

During the build process, the following are moved to /usr/share/tails:
- /usr/share/i2p
- /usr/sbin/wrapper to /usr/share/tails/i2p
- /usr/share/applications/i2p.desktop to /usr/share/tails/i2p

The I2P binaries are changed to be owned by i2psvc:i2psvc to prevent it
being run from the new location under /usr/share/tails/i2p.

If the string 'i2p' is entered on at the boot prompt, these files are
returned to ther original locations, making I2P accessible. Also, the
I2P sudoers file is written to the system, allowing the amnesia user to
run tails-start-i2p as the i2psvc user.
---
 config/chroot_local-hooks/97_remove_i2p            | 19 +++++++++++++++
 config/chroot_local-includes/etc/sudoers.d/zzz_i2p |  1 -
 .../lib/live/config/2080-install-i2p               | 27 ++++++++++++++++++++++
 wiki/src/contribute/design/I2P.mdwn                |  6 +++++
 wiki/src/doc/anonymous_internet/i2p.mdwn           | 11 +++++++--
 5 files changed, 61 insertions(+), 3 deletions(-)
 create mode 100755 config/chroot_local-hooks/97_remove_i2p
 delete mode 100644 config/chroot_local-includes/etc/sudoers.d/zzz_i2p
 create mode 100755 config/chroot_local-includes/lib/live/config/2080-install-i2p


diff --git a/config/chroot_local-hooks/97_remove_i2p b/config/chroot_local-hooks/97_remove_i2p
new file mode 100755
index 0000000..16b43b7
--- /dev/null
+++ b/config/chroot_local-hooks/97_remove_i2p
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+set -u
+set -e
+
+# Everything moved by this hook script will be reversed in the event that
+# the string "i2p" is entered at a boot prompt
+
+DEST="/usr/share/tails"
+
+[ -d "/usr/share/i2p" ] || return 0
+
+# Let's make sure that *just* the "i2psvc" user has access to the I2P files
+chown -R i2psvc:i2psvc /usr/share/i2p
+find /usr/share/i2p -type f \( -name '*.jar' -o -name '*.war' \) -print0 | xargs -r -0 chmod 640
+
+mv -f /usr/share/i2p "$DEST"
+mv -f /usr/sbin/wrapper "$DEST/i2p"
+mv -f /usr/share/applications/i2p.desktop "$DEST/i2p"
diff --git a/config/chroot_local-includes/etc/sudoers.d/zzz_i2p b/config/chroot_local-includes/etc/sudoers.d/zzz_i2p
deleted file mode 100644
index 60f5c6c..0000000
--- a/config/chroot_local-includes/etc/sudoers.d/zzz_i2p
+++ /dev/null
@@ -1 +0,0 @@
-amnesia   ALL = NOPASSWD: /etc/init.d/i2p
diff --git a/config/chroot_local-includes/lib/live/config/2080-install-i2p b/config/chroot_local-includes/lib/live/config/2080-install-i2p
new file mode 100755
index 0000000..ffebeba
--- /dev/null
+++ b/config/chroot_local-includes/lib/live/config/2080-install-i2p
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+set -e
+set -u
+
+# This script reverses everything done by config/chroot_local-hooks/97_remove_i2p
+# when the string "i2p" is added to the boot prompt.
+
+grep -qw "i2p" /proc/cmdline || return 0
+SRC="/usr/share/tails/i2p"
+[ -d "$SRC" ] || return 0
+
+Install_I2P(){
+    mv "$SRC/wrapper" /usr/sbin/wrapper
+    mv "$SRC/i2p.desktop" /usr/share/applications
+    mv "$SRC" /usr/share
+    chown -R i2psvc:i2psvc /usr/share/i2p
+}
+
+Add_Sudo_Config(){
+    echo "amnesia   ALL = NOPASSWD: /etc/init.d/i2p" > /etc/sudoers.d/zzz_i2p
+    chown root:root /etc/sudoers.d/zzz_i2p
+    chmod 644 /etc/sudoers.d/zzz_i2p
+}
+
+Install_I2P
+Add_Sudo_Config
diff --git a/wiki/src/contribute/design/I2P.mdwn b/wiki/src/contribute/design/I2P.mdwn
index 789d584..8451e3a 100644
--- a/wiki/src/contribute/design/I2P.mdwn
+++ b/wiki/src/contribute/design/I2P.mdwn
@@ -15,6 +15,12 @@ Versions
 preconfigured using FoxyProxy so that eepsites (`.i2p` TLD) are directed to
 I2P. All other traffic gets routed through Tor.


+Starting with Tails v1.1.1, I2P is not enabled by default when Tails starts.
+In order to use I2P, add the <span class="command">i2p</span> boot option
+to the <span class="application">boot menu</span>. For detailed
+instructions, see the documentation on [[using the <span
+class="application">boot menu</span>|first_steps/startup_options#boot_menu]].
+
<a id="design"></a>

Design
diff --git a/wiki/src/doc/anonymous_internet/i2p.mdwn b/wiki/src/doc/anonymous_internet/i2p.mdwn
index 1a87010..8f7c75f 100644
--- a/wiki/src/doc/anonymous_internet/i2p.mdwn
+++ b/wiki/src/doc/anonymous_internet/i2p.mdwn
@@ -24,8 +24,15 @@ top level domain (similar to `.onion` for Tor hidden services). For
instance, the I2P homepage can also be accessed through I2P via
<http://i2p-projekt.i2p>.

-I2P is not started by default in Tails, but can be started manually
-throught the menu:
+Starting with Tails 1.1.1, I2P is not enabled by default when Tails starts.
+In order to use I2P, add the <span class="command">i2p</span> boot option
+to the <span class="application">boot menu</span>. For detailed
+instructions, see the documentation on [[using the <span
+class="application">boot
+menu</span>|first_steps/startup_options#boot_menu]].
+
+Once enabled at the boot prompt, I2P can be started manually
+through the menu:

     Applications -> Internet -> i2p


--
2.0.1

From df8100fd6a02b72d1d871ccaabe9aa574c7ac320 Mon Sep 17 00:00:00 2001
From: Kill Your TV <killyourtv@???>
Date: Wed, 30 Jul 2014 01:44:03 +0000
Subject: [PATCH 2/4] stricter I2P fw rules

This commit will:
- deny I2P from accessing the LAN
- deny I2P from accessing the loopback device, except for select
whitelisted services
- allow I2P access to the Internet

The ACCEPT rules will only be enabled when the string 'i2p' is passed at
the boot prompt.

The rules which DENY or REJECT access for the 'i2psvc' user will always
be applied.
---
config/chroot_local-includes/etc/ferm/ferm.conf | 26 +++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/config/chroot_local-includes/etc/ferm/ferm.conf b/config/chroot_local-includes/etc/ferm/ferm.conf
index 54ab253..25d1d02 100644
--- a/config/chroot_local-includes/etc/ferm/ferm.conf
+++ b/config/chroot_local-includes/etc/ferm/ferm.conf
@@ -3,6 +3,11 @@
# Configuration file for ferm(1).
#

+# I2P rules that grant access to the "i2psvc" user (those with $use_i2p) will
+# only be enabled if the string "i2p" is entered at the boot prompt.
+# Deny or reject rules affecting "i2psvc" will always be set.
+def $use_i2p = `test -d /usr/share/i2p && echo 1 || echo 0`;
+
 # IPv4
 domain ip {
     table filter {
@@ -60,6 +65,7 @@ domain ip {
                 # White-list access to system DNS and Tor's DNSPort
                 daddr 127.0.0.1 proto udp dport (53 5353) {
                     mod owner uid-owner amnesia ACCEPT;
+                    @if $use_i2p mod owner uid-owner i2psvc ACCEPT;
                 }


                 # White-list access to ttdnsd
@@ -76,12 +82,17 @@ domain ip {
                     mod owner uid-owner amnesia ACCEPT;
                 }


-                # White-list access to I2P
+                # White-list access to I2P services for both the amnesia user (client) and i2psvc (server)
                 # For more information, see https://tails/boum.org/contribute/design/I2P and https://geti2p.net/ports
                 daddr 127.0.0.1 proto tcp syn mod multiport destination-ports (2827 4444 4445 6668 7656 7657 7658 7659 7660 8998) {
-                    mod owner uid-owner amnesia ACCEPT;
+                    @if $use_i2p mod owner uid-owner (amnesia i2psvc) ACCEPT;
+                }
+                # White-list access to the java wrapper's (used by I2P) control ports
+                # (see: http://wrapper.tanukisoftware.com/doc/english/prop-port.html)
+                # If, for example, port 31000 is in use, it'll try the next one in sequence.
+                daddr 127.0.0.1 proto tcp sport (31000 31001 31002) dport (32000 32001 32002) {
+                    @if $use_i2p mod owner uid-owner i2psvc ACCEPT;
                 }
-


                 # White-list access to CUPS
                 daddr 127.0.0.1 proto tcp syn dport 631 {
@@ -104,19 +115,22 @@ domain ip {
             }


             # Local network connections should not go through Tor but DNS shall be
-            # rejected.
+            # rejected. I2P is explicitly blocked from communicating with the LAN.
             # (Note that we exclude the VirtualAddrNetwork used for .onion:s here.)
             daddr (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16) @subchain "lan" {
                 proto tcp dport domain REJECT;
                 proto udp dport domain REJECT;
+                mod owner uid-owner i2psvc REJECT;
                 ACCEPT;
             }


             # Tor is allowed to do anything it wants to.
             mod owner uid-owner debian-tor ACCEPT;


-            # i2p is allowed to do anything it wants to.
-            mod owner uid-owner i2psvc ACCEPT;
+            # i2p is allowed to do anything it wants to on the internet.
+            outerface ! lo mod owner uid-owner i2psvc {
+                @if $use_i2p proto (tcp udp) ACCEPT;
+            }


             # Everything else is logged and dropped.
             LOG log-prefix "Dropped outbound packet: " log-level debug log-uid;
-- 
2.0.1


From 148f429d0135334b75c5bba4668c8617a2603b51 Mon Sep 17 00:00:00 2001
From: Kill Your TV <killyourtv@???>
Date: Thu, 31 Jul 2014 00:02:18 +0000
Subject: [PATCH 3/4] disable I2P plugins

Plugins for I2P--without using persistence--don't make much sense.
A default of 'disable' here may also eliminate a possible attack vector.

I know of some Tails users that use I2P-Bote, a mail-like application
available as an I2P plugin, and they manually enable persistence for
I2P. A user that is able to manually enable persistence can easily
re-enable plugin support, if desired.
---
 config/chroot_local-hooks/16-i2p_config |  2 ++
 wiki/src/contribute/design/I2P.mdwn     | 12 +++++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)


diff --git a/config/chroot_local-hooks/16-i2p_config b/config/chroot_local-hooks/16-i2p_config
index cf1a8f2..42cd2b2 100755
--- a/config/chroot_local-hooks/16-i2p_config
+++ b/config/chroot_local-hooks/16-i2p_config
@@ -30,6 +30,7 @@ sed -i 's|^.*\(wrapper\.java\.additional\.6=-Djava\.net\.preferIPv6Addresses=\).
# * HiddenMode: Enabled
# * In-I2P Network Updates: Disabled
# * Inbound connections: Disabled (setting is "i2cp.ntcp.autoip")
+# * Disable I2P plugins
cat > "$I2P/router.config" << EOF
# NOTE: This I2P config file must use UTF-8 encoding
i2cp.disableInterface=true
@@ -38,4 +39,5 @@ i2np.ntcp.autoip=false
i2np.udp.ipv6=false
router.isHidden=true
router.updateDisabled=true
+router.enablePlugins=false
EOF
diff --git a/wiki/src/contribute/design/I2P.mdwn b/wiki/src/contribute/design/I2P.mdwn
index 8451e3a..1b81f07 100644
--- a/wiki/src/contribute/design/I2P.mdwn
+++ b/wiki/src/contribute/design/I2P.mdwn
@@ -85,7 +85,7 @@ configuration handling the I2P integration. FoxyProxy's whitelist
filter is used to make sure that the corresponding urls will be
proxied appropriately.

-Below are the patterns that each url handeled by iceweasel will be
+Below are the patterns that each url handled by iceweasel will be
matched against. These patterns will be tried in order, from top to
bottom, until the first match is found:

@@ -156,6 +156,16 @@ will not be an issue unless one wants to
In order to utilize these features users need to set an
[[doc/first_steps/startup_options/administration_password]].

+Changes from upstream
+=====================
+
+* i2cp, allowing java clients to communicate with I2P from outside of the JVM, is disabled
+* IPv6 is disabled
+* HiddenMode is set for all users
+* Updating I2P from within the I2P network is disabled; updates are done using the .debs
+* Inbound connections are disabled
+* I2P plugins are disabled
+
Package source and upgrading I2P
================================

--
2.0.1

From 50ab6097e22f0cb343befbe9812e92f565c2314b Mon Sep 17 00:00:00 2001
From: Kill Your TV <killyourtv@???>
Date: Thu, 31 Jul 2014 17:11:51 +0000
Subject: [PATCH 4/4] I2P: Keep POP3 email on server

The default in the I2P webmail app was to keep mail on the server, but
that setting was changed recently.

This configuration setting (susimail.config) will only be copied over in
I2P 0.9.14 and newer.
---
 config/chroot_local-hooks/16-i2p_config | 4 ++++
 wiki/src/contribute/design/I2P.mdwn     | 1 +
 2 files changed, 5 insertions(+)


diff --git a/config/chroot_local-hooks/16-i2p_config b/config/chroot_local-hooks/16-i2p_config
index 42cd2b2..d3332f4 100755
--- a/config/chroot_local-hooks/16-i2p_config
+++ b/config/chroot_local-hooks/16-i2p_config
@@ -41,3 +41,7 @@ router.isHidden=true
router.updateDisabled=true
router.enablePlugins=false
EOF
+
+cat > "$I2P/susimail.config" << EOF
+susimail.pop3.leave.on.server=true
+EOF
diff --git a/wiki/src/contribute/design/I2P.mdwn b/wiki/src/contribute/design/I2P.mdwn
index 1b81f07..831f2e4 100644
--- a/wiki/src/contribute/design/I2P.mdwn
+++ b/wiki/src/contribute/design/I2P.mdwn
@@ -165,6 +165,7 @@ Changes from upstream
* Updating I2P from within the I2P network is disabled; updates are done using the .debs
* Inbound connections are disabled
* I2P plugins are disabled
+* The webapp `susimail` will leave mail on the server

Package source and upgrading I2P
================================
--
2.0.1