Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gentoo rsync considered harmful (MITM)? Straw-man solution.
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
Sakaki
Tux's lil' helper
Tux's lil' helper


Joined: 21 May 2014
Posts: 94

PostPosted: Mon Sep 11, 2017 11:55 am    Post subject: Gentoo rsync considered harmful (MITM)? Straw-man solution. Reply with quote

Hello,

I'm in the process of updating my EFI Install Guide, and it prompted me to consider whether it is sensible to recommend new users keep their Portage tree up-to-date via rsync (as is the handbook default). The problem being, of course, that rsync is an unauthenticated protocol and as such open to man-in-the-middle (MITM) attacks (e.g., supplying corrupted ebuilds or manifests), which could easily root the machine. This is a non-trivial concern for those using Gentoo in e.g. countries with repressive regimes.

The issue has been raised before (see e.g. bug 597804), and of course there are instructions in the handbook for using webrsync-gpg, but that's quite bandwidth inefficient (and most users will only get to this after doing a standard install anyhow, by which point it may already be too late).

As a possible solution to this, an approach I have taken with my own weekly-gated Portage snapshots (for the gentoo-on-rpi3-64bit project) is to use a simple script to create a signed 'master' hash of the (recursive) contents of the /usr/portage directory (and its 'stat' metadata, under LC_ALL="C"). The script to compute this, "porthash", will win no programming awards, but may be reviewed on GitHub here. From its help text:
Code:
Usage: /usr/bin/porthash [options]

Create, or verify (default), a signed hash of full Portage tree
The hash is saved to repo.hash, the signature to
repo.hash.asc

Useful when distributing snapshots via e.g. rsync
Hash covers all file contents (recursively), and also the
ownership, filetype and permissions of all files and directories.

The hash does _not_ cover the distfiles, packages or .git directories,
nor the repo.hash or repo.hash.asc files themselves. It will also
exclude the metadata directory, unless the -m option is given.

Options:
  -c, --create        Create a new master hash (and sign it)
                      (default is to verify an existing hash)
  -h, --help          Show this help screen and exit
  --homedir=HOMEDIR   Use HOMEDIR as gpg's home (default: /root/.gnupg)
  --key=KEYID         Use key KEYID to verify/sign (default: 5D90CAF4)
  -m, --metadata      Include metadata directory when creating hash
                      (omitted by default)
  --repo=RDIR         Repository tree location (default: /usr/portage)
  -v, --version       Show version number of porthash and exit


This script is run (on the server side, with an appropriate private key and the "-c" option specified) whenever the repo is changed. It takes around 5 seconds wall time to complete on my Xeon E5-2696v4 machine. Two additional files are created (both <1KiB), /usr/portage/repo.hash and /usr/portage/repo.hash.asc.

It is then run again (without -c) by an /etc/portage/repo.postsync.d hook on the client machine whenever a sync of the main repo is performed, to verify the signed master hash (and bail out with a vocal error if a problem is detected).

This has been deployed now for a while (for users of the gentoo-on-rpi3-64bit project) and appears to be working fine. Could a similar approach not be adopted for Gentoo's main rsync repo (using release engineering signatures, of course)? It would add only a small additional computational load to the root server (invoked whenever one or more files was changed) and would be backwards compatible with existing practice (users not wanting to check the repo master hash would only have two small additional files in their /usr/portage directory).

Comments welcome ^-^
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
nokilli
Apprentice
Apprentice


Joined: 25 Feb 2004
Posts: 151

PostPosted: Mon Sep 11, 2017 12:23 pm    Post subject: Reply with quote

Isn't the plan to move from rsync to git?

And then the plan is for git to move from SHA-1 to SHA-3?
_________________
Today is the first day of the rest of your Gentoo installation.
Back to top
View user's profile Send private message
Sakaki
Tux's lil' helper
Tux's lil' helper


Joined: 21 May 2014
Posts: 94

PostPosted: Mon Sep 11, 2017 1:00 pm    Post subject: Reply with quote

Agreed, syncing the repo via git over an authenticated channel (esp. with mandatory signed commits) would obviate this issue completely.

But until that is the status quo for Portage (and reflected in the handbook etc.), I was suggesting something that could be integrated into the existing sync workflow with minimal cost / disruption.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
tholin
Tux's lil' helper
Tux's lil' helper


Joined: 04 Oct 2008
Posts: 91

PostPosted: Mon Sep 11, 2017 8:05 pm    Post subject: Reply with quote

It's good that someone is thinking about ways to improve portage sync. The insecure-by-default sync is probably gentoo's biggest wart.

I think gpg returns success even if the signing key has expired so you might want to check if the gpg key is still valid.

The hashfile contains the time the hash was generated but that info is not verified. verify_master_hash should make sure the date of the current hash is more recent than the previous hash to protect against downgrade attacks. Portage got its own timestamp file at /usr/portage/metadata/timestamp.x but I don't think portage use that for protecting against downgrades.

It looks like compute_master_hash reads every file in the portage tree every time, except some excluded directories. That might take 5sec with warm caches but on my system with cold caches it takes 45sec. emerge-webrsync only takes 39sec with cold caches and a 100Mbit connection. Since porthash will run right after rsync caches will be partially warm but most file content will not be cached.

Perhaps another way to do the hashing would be to use a merkle tree. The portage tree is already a tree so files could be treated like leafs and directories as non-leafs. That way changing a few files would only require hashing a subset of the full tree.
https://en.wikipedia.org/wiki/Merkle_tree
Sakaki wrote:
Agreed, syncing the repo via git over an authenticated channel (esp. with mandatory signed commits) would obviate this issue completely.

I'm not entirely sure how the git sync works but I think those signed commits also need to be checked at sync time. That's not done(?) so an evil mirror (github) could send any git repo it wants. Checking those signatures will require all signing keys from every developer and I don't know what happens when a key is lost and you have to do key revocation. There also needs to be some way to protect against downgrade attacks.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum