[Ksummit-discuss] [CORE TOPIC] dev/maintainer workflow security

Konstantin Ryabitsev konstantin at linuxfoundation.org
Mon Jul 13 16:05:41 UTC 2015


On Mon, Jul 13, 2015 at 04:39:20PM +0100, James Bottomley wrote:
> > I'm far from suggesting that we make this mandatory, but I'm open to
> > any suggestions on how we can make more developers enroll with 2fa.
> 
> It's a bit painful for those of us who move around a lot and no-one has
> ever articulated a clear threat vector it's supposed to counter.
> 
> In fact, I'd argue it gives a false sense of security: the ssh keys and
> authentication factors aren't what I'd go after if I were attacking
> kernel.org because anything I pushed using a stolen key would instantly
> be noticed the next time the maintainer pushed and the tree wouldn't
> fast forward.  If I were trying to get a bogus commit into the tree, I'd
> be attacking the maintainer's laptop to put it into their personal git
> tree (I'd actually tack the code on to an existing commit via rebase ...
> cleverly choosing a commit they hadn't yet pushed), so no-one would
> notice when it was pushed to kernel.org and it would be properly
> accounted for in the subsequent pull request to Linus.  2 factor
> authentication does nothing to counter this.

It counters several vectors of attack:

1. Someone makes a commit to your repo while you are on an extended trip
   and it percolates to other repos that pull from you. When you notice
   this upon your return, it's already been widely disseminated.
2. When multiple developers are working on the same repository, an attacker
   can time a commit when one of the developers is about to step away for a
   few days (travel, conference, etc). When the developer is back, they
   are going to do a "git pull" as first thing, to get the latest
   commits from other developers and will therefore likely miss "their
   own" missing commit, pulling it in their tree.
3. Developers who use multiple systems (home workstation and a travel
   laptop, for example) will routinely perform a "git pull" to keep
   their trees in sync and it would be fairly easy to time an injection
   into the tree to sneak in a commit.

Getting private ssh keys is a lot easier than getting full access to a
developer's workstation:

- Many developers ssh to systems without restricting agent forwarding to
  a set of trusted systems only, which would allow an attacker on a
  compromised system to ssh to gitolite.kernel.org with developer's
  credentials.
- Many 0-days in client tools allow full access to local content, but
  not necessarily an ability to execute arbitrary commands.
- I'm willing to bet there are lots of removable storage floating around
  people's workdesks and travel bags that contain full copies of their
  homedirs for backup purposes (tell me it ain't true!).

The 2fa solution we have certainly doesn't solve all possible problems,
but it does have very good reasons to exist.

Regards,
-- 
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-discuss/attachments/20150713/cab69455/attachment.sig>


More information about the Ksummit-discuss mailing list