I2P client inside Whonix-Workstation Issues

Support
3

Restarting the system after configuring I2P for automatic boot with dpkg-reconfigure i2p didn’t create the directory.

Listing of services with systemctl list-units --type=service --state=running does not show I2P.

Tried sudo service i2p start and sudo systemctl start i2p. No errors but service does still not show up with systemctl list-units --type=service --state=running. Directory /var/lib/i2p/ is still empty.

Tried i2prouter start but this created the configuration files on the home directory which is not desired. I restarted the setup procedure on a new Qubes whonix-ws-16 Template after that. So still no solution. What is the mistake here?

1 Like
4

Not sure. We may have possible issues with Kicksecure or immutable state at the moment, but I’m not prepared to debug them yet. I should be able to make more time for that next week.

1 Like
5

Thanks. My workaround will be to start I2P with i2prouter start. I get two popups with “Do not run Tor Browser in Template” then. Should I anyhow consider these in a specific way? Can not explain why they come up.

I will change the 127.0.0.1 to 127.0.02 according to https://www.whonix.org/wiki/I2P#I2P_client_inside_Whonix-Workstation in this file: /home/user/.i2p/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config

I will keep starting I2P with i2prouter start on App VM manually.

Any comments on this workaround?

6

I found that the config files were created in the Qubes App VM instead of the template. I guess the steps in the instruction under Usage (https://www.whonix.org/wiki/I2P#Usage) have to be performed on App VMs instead of the Template. Maybe the instruction needs to be updated then if I am right.

@Patrick Could you please confirm?

7

Do not run Tor Browser in Template popup is correct. See also:

Tor Browser Essentials chapter In Qubes-Whonix in Whonix wiki

8

Fixed, check the wiki after few hours once get updated.

Thats bad way to start I2P because it wont load apparmor I2P profile for it, thats why its not mentioned in the wiki.

1 Like
9

The current state is that when you run dpkg-reconfigure i2p in the Whonix Template (whonix-ws-16-clone-1), it does not create the configuration files under /var/lib/i2p/.

I don’t currently see a suitable way to do this,. The instructions in the wiki do not work after step 3.

Current alternative according to https://forums.whonix.org/t/i2p-integration/4981/355 is after doing steps 1-3 in the Whonix Template (whonix-ws-16-clone-1):

  1. Shutdown Whonix Template (whonix-ws-16-clone-1)
  2. Start Whonix-Workstation AppVM (anon-whonix-I2P) based on Whonix Template (whonix-ws-16-clone-1)
    Following steps have to be done on every restart of the AppVM due to non-persistance.
  3. Run dpkg-reconfigure i2p which also start i2p and creates configuration files in /var/lib/i2p/
  4. Stop I2P service with sudo systemctl stop i2p
  5. Use sudoedit /var/lib/i2p/i2p-config/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config and change 127.0.01 to 127.0.0.2.
  6. Start I2P service with sudo systemctl start i2p
  7. Optional: Adjust I2P Router configuration

The following step only needs to performed once and after TB updates.

  1. Configure TB for usage with I2P

TB can be used to access I2P pages. TB can not be used to access onion addreses (Outproxy not found). TB can be used to access clearnet.

Questions

Step 1 in the wiki (Securely Download of the Key): Why should should someone securely download the key to the Whonix-Workstation as mentioned in step 1 of the wiki instead of downloading it to Whonix Template only? Or is this necessary for every case?

Using I2P-modified TB to access clearnet: Should we avoid this due to security considerations and why?

Regarding step 7: Do we have to configure router.config.anondist in /usr/share/i2p/ or /var/lib/i2p/i2p-config/ to be effective?

Any other things to consider with this setup in terms of security or anonymity?

Are there any solution to be able to setup I2P service and configuration files in Whonix Template (whonix-ws-16-clone-1)?

10

That might be because I2P is unable to connect so it doesn’t create that config folder.

I2P seems weird in that way anyhow. That it needs connectivity to create that config file. And also the config file location is weird.

Could step “Change I2Pconsole interface local IP change.”

Open file /var/lib/i2p/i2p-config/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config in an editor with root rights.

Change from 127.0.0.1 to 127.0.0.2.

be done in some other file in /etc instead or the config file be created without need to start I2P? @eyedeekay

It doesn’t say that.

  • If you are using Whonix-Workstation ™ (anon-whonix), run.

  • If you are using a Qubes Template (whonix-ws-16 ), run.

gpg key download in Qubes templates is an issue unspecific to Whonix.

See this lengthy discussion on that topic in the Qubes forums:

The web fingerprint is modified. Therefore best to use

  • multiple Whonix-Workstation (better), or
  • multiple Tor Browser

(All documented in the wiki.)

These numbers might frequently change unfortunately as this documentation is keep getting updated.

Another issue.
I2P doesn’t seem to support /etc/i2p.d and/or /usr/local/etc/i2p.d. Not sure there is now.

Any update on /etc/i2p.d? @eyedeekay

Modifications to /usr/share/i2p/router.config will be lost after the next update of package anon-apps-config unfortunately. To solve this, upstream support for /etc/i2p.d is required.

1 Like
11

They ended up in /var/lib/i2p/i2p-config/i2ptunnel.config.d and /var/lib/i2p/i2p-config/clients.config.d. You can create the clients.config.d files and i2ptunnel.config.d files in advance but IIRC you’ll need to create one for each app you intend to run on your node because the defaults will not be “migrated” from the initial, monolithic config. So you will need to create a config file for every app. The reason it appears that I2P needs connectivity to create these config files is because this migration happens when the apps are started which only happens after the API’s become available which only happens after we connect successfully. It doesn’t intrinsically need to be that way.

There isn’t an equivalent with router.config, but dropping a router.config file in /var/lib/i2p/i2p-config/router.config should change the values your router uses when you set it up.

I’ll get back to you on how to move this all into a directory in /etc/ instead of /var/lib/ as soon as I look it up. /var/lib/i2p/ is the i2psvc user’s home directory and moving it would require changing that directory and changing the AppArmor profile to match. This is all handled by debian.preinst, debian.postinst files in the debian directory. wrapper.config is the only one that goes into /etc/i2p. But(And I haven’t tried this yet) what you may be able to do is possibly create a directory called /etc/i2p/i2p-dir for instance which is owned by the i2psvc user and in /etc/i2p/wrapper.config add the line wrapper.java.additional.3=-Di2p.dir.config=/etc/i2p/i2p-dir. That would cause it to use /etc/i2p/i2p-dir as the working directory instead and therefore the config files would be placed in /etc/i2p/i2p-dir/clients.config.d /etc/i2p/i2p-dir/i2ptunnel.config.d/ instead. Doesn’t address the AppArmor thing though.

1 Like
12

Is it effective to configure router.config in /var/lib/i2p/i2p-config/router.config instead of /usr/share/i2p/router.config?

What is the difference between router.config and router.config.anondist?

13

There is a solution circulating, in which it is described that the service I2P should be started with i2prouter start to create the config files in /home/user/.i2p/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config.

On a Whonix Template using the command i2prouter start creates the files on the Template but they are not available in the Template-based AppVM afterwards. I guess this has something to do with the Qubes standard persistence settings.

Therefore on the Template-based AppVM you can run i2prouter start which creates configuration files persistent in/home/user/.i2p/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config. Note: sudo dpkg-reconfigure i2p creates configuration files in /var/lib/i2p/ on AppVM only.

Conclusion:

  • i2prouter start creates configuration files in /home/user/.i2p/ and works on Template and AppVM.
  • sudo systemctl start i2p creates configuration files in /var/lib/i2p/ but does not work on Whonix Template.
  • There is currently no way to get the configuration files created in a Whonix Template which are available on the accoding Template-based AppVM as /home/user/ gets overwritten in AppVM.
  • Creating configuration files must be done in the Template-based AppVM by starting I2P: 1) With i2prouter start you get the configuration files persistent, with sudo systemctl start i2p you have to create and change configuration files on each restart of the AppVM.

Is it a secure and reliable alternative to use i2prouter start in AppVM so that you don’t have to reconfigure the configuration files on each restart of the AppVM?

14

The Qubes particularities on how (non-)persistence is implemented meet I2P’s particularities on how config files are handled. In combination, these are creating a usability mess.

Ignore .anondist. This doesn’t need user documentation. Nothing special to know. No big deal.

Details:

ls -la /var/lib/i2p/i2p-config/router.config*

related:
Dev/About Debian Packaging - Kicksecure chapter config-package-dev in Kicksecure wiki

Normal Qubes persistence “issue” if you can call it an issue.

I doubt that.

Quite possibly because I2P only creates the config files when connectivity is available, which is even more weird. And connectivity is limited in Qubes Templates by Qubes design (at time of writing, only the package manager by default can use networking).

15

It’s not that weird if you consider that I2PSnark, Hidden Services Manager, and even the Router Console are actually separate applications, which will run only after I2P itself is successfully started. Starting them before I2CP is available would not make sense in the same way that allowing Tor Browser to fetch pages before a SOCKS proxy was available would not make sense. The result is that you start with what we call a “monolithic” config file where all the stuff is stored in one file, called clients.config and i2ptunnel.config respectively, which is immediately migrated to a directory config on most platforms. We did it this way because the monolithic config files are still used on places where the base config directory(/usr/share/i2p) and the working config directory(/var/lib/i2p/i2p-config) are the same which includes Android and Portable installations, so this way we still only need to maintain one config file.

However, if a directory config is already present, the migration will not occur. So if you just drop all your custom I2P config files into /var/lib/i2p/i2p-config they won’t be migrated from the defaults in /usr/share/i2p, including router.config. Everything you don’t include in that config(keys, etc) should be regenerated at runtime, and if it doesn’t file an issue and we’ll take care of it on our end.

1 Like
16

Ok, maybe we’re getting somewhere! :slight_smile: Appreciate all your support!

It’s a drop-in folder where distribution maintainers (Whonix) and/or users can drop snippets…?

In that case…

  1. Whonix should stop telling users to edit /var/lib/i2p/i2p-config/clients.config.d/00-net.i2p.router.web.RouterConsoleRunner-clients.config since there no need for it.
  2. Whonix should stop shipping the config-package-dev diverted file /usr/share/i2p/router.config since there’s no need for that either.
  3. Whonix should drop its config snippet(s) into the /var/lib/i2p/i2p-config folder? Any file name possible?

Sounds like a plan?

Or would it be more appropriate for Whonix to use /usr/share/i2p folder to drop snippets?

What’s the config line that we need to add to accomplish

Change from 127.0.0.1 to 127.0.0.2 .

?

17

Sorry it took me a little longer to get back to you. Had a developer leave the project, need to re-allocate some work and offboard him. So let’s see…

It’s a drop-in folder where distribution maintainers (Whonix) and/or users can drop snippets…?

Well yes, in that there are places it looks for default configuration files and if you have an existing configuration in that directory it won’t generally interfere with those settings. If we have to touch one of your settings when we configure your router, we also have to publish something about why, couple examples, we had to reach in and enable “Tunnel Testing” in an update to the Java I2P router a few releases ago in order to avoid a conflict with i2pd routers, and I had to change the update URL in the Easy-Install for Windows due to a conflict with de-coupled I2P routers(Easy-Install for Windows is a bundle). The point is, if you put a config file in the config directory, we don’t change the settings unless it’s really, really important.

  1. Whonix should stop telling users to edit /var/lib/i2p/i2p-config/clients.config.d/00- net.i2p.router.web.RouterConsoleRunner-clients.config since there no need for it.
  2. Whonix should stop shipping the config-package-dev diverted file /usr/share/i2p/router.config since there’s no need for that either.
  3. Whonix should drop its config snippet(s) into the /var/lib/i2p/i2p-config folder? Any file name possible?

Yes to 2 and 3, if I understand correctly, but

2. Possibly put router.config.anondist into /var/lib/i2p/i2p-config/router.config instead.

3. You can either use /var/lib/i2p/i2p-config/i2ptunnel.config and /var/lib/i2p/i2p-config/clients.config in which case the names matter, or you can use /var/lib/i2p/i2p-config/i2ptunnel.config.d and /var/lib/i2p/i2p-config/clients.config.d in which case the directory names matter but any filename is OK as long as it ends in .config

3.a: If you use /var/lib/i2p/i2p-config/i2ptunnel.config and /var/lib/i2p/i2p-config/clients.config simply make your edits* to the default config files and place them in the /var/lib/i2p/i2p-config directory. They will be migrated on the first run to directory configs. Otherwise everything will function normally.

3.b: If you use /var/lib/i2p/i2p-config/i2ptunnel.config.d/ and /var/lib/i2p/i2p-config/clients.config.d/, pre-populate it with all the config files you need, i.e. the migrated versions of the default clients tunnels. In these directories any file with a name ending in .config will be read for a configuration.

Change from 127.0.0.1 to 127.0.0.2 .

Those would occur in clients.config or the corresponding clients.config.d directory, and i2ptunnel.config or the corresponding i2ptunnel.config.d directory. Change any value which you want to be reachable on a different address to that different address.

1 Like
18

A post was merged into an existing topic: I2P Integration

19

Any chance you could send a pull request to anon-apps-config implementing the better config style please?

Main goals:

  • As simple as possible for users in the end.
  • Use .d style config files whenever possible.
  • Avoid need to start I2P just to have it create a default config file and then we having to tell users they need to edit that file. In other words, instructions such as 1. start I2P, 2. edit that file… Not great. Best avoided.
  • Ideally all the user would have to do would be installing I2P and all the Whonix specific settings required are already preconfigured and nicely contained in the anon-apps-config package.
20

Yeah I can probably make that happen after the I2P release on the 22nd, maybe a little sooner.

2 Likes
21

Yay!

Quote @eyedeekay

I believe this will accomplish what is discussed ITT: I2P client inside Whonix-Workstation Issues - #18 but it wants for testing on an actual Whonix system, I’ve only tried it on regular Debian so far. It changes the default address for user-facing services to 127.0.0.2 instead of 127.0.0.1 using config.d files placed in the i2p-config directory and applies the Whonix-specific router.config using i2p-config instead of using the base configuration. This should require no intervention from the user to set up.

22

Merged. Thank you!

Added a few commits on top.

This is making a bit of trouble:

## Fix permissions on the I2P configuration directory.

chown -R i2psvc:i2psvc /var/lib/i2p/i2p-config/
  • (Would fail if folder does not exist (but I tried to avoid that by just using mkdir --parents) but then…)
  • Would fail if user and/or group i2psvc does not exist.
  • And lintian complains.
################################################################################
W: anon-apps-config: recursive-privilege-change postinst:56
N:
W: recursive-privilege-change
N:
N:   The named maintainer script appears to call chmod or chown with a
N:   --recursive/-R argument, or it uses find(1) with similar intent.
N:   
N:   All such uses are vulnerable to hardlink attacks on mainline (i.e.
N:   non-Debian) kernels that do not set fs.protected_hardlinks=1.
N:   
N:   The security risk arises when when a non-privileged user set links to
N:   files they do not own, such as such as /etc/shadow or files in
N:   /var/lib/dpkg/. A superuser's recursive call to chown or chmod on
N:   behalf of a role user account would then modify the non-owned files in
N:   ways that allow the non-privileged user to manipulate them later.
N:   
N:   There are several ways to mitigate the issue in maintainer scripts:
N:   
N:    - For a static role user, please call chown at build time
N:      and not during the installation.
N:    - If that is too complicated, use runuser(1) in the
N:      relevant build parts to create files with correct ownership.
N:    - Given a static list of files to change, use non-recursive calls
N:      for each file. (Please do not generate the list with find.)
N:   
N:   Refer to Bug#895597, Bug#889060, Bug#889488, and the runuser(1) manual
N:   page for details.
N:   
N:   Severity: warning
N:   
N:   Check: scripts
N:   
N:   Renamed from:
N:   maintainer-script-should-not-use-recursive-chown-or-chmod
N:
################################################################################

Hence asking is chown -R i2psvc:i2psvc /var/lib/i2p/i2p-config/ very important or will the i2p package later take care of setting proper permissions? That would be much better.

Meanwhile therefore I ported that part to systemd tmpfiles.d.