ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] dev/maintainer workflow security
Date: Mon, 13 Jul 2015 12:05:41 -0400	[thread overview]
Message-ID: <20150713160541.GC15582@gmail.com> (raw)
In-Reply-To: <1436801960.6901.19.camel@HansenPartnership.com>

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2015-07-13 16:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 14:38 Jason Cooper
2015-07-10 15:50 ` Josh Boyer
2015-07-10 16:23   ` Theodore Ts'o
2015-07-10 19:45     ` Steven Rostedt
2015-07-10 20:34       ` Olof Johansson
2015-07-11  1:19         ` Jason Cooper
2015-07-10 22:08     ` Kees Cook
2015-07-11  1:48       ` Jason Cooper
2015-07-11  7:31       ` James Bottomley
2015-07-11 16:02         ` Jason Cooper
2015-07-11 16:38           ` Theodore Ts'o
2015-07-13 23:15             ` Kees Cook
2015-07-13  8:32         ` Jiri Kosina
2015-07-13 14:07           ` Konstantin Ryabitsev
2015-07-13 15:39             ` James Bottomley
2015-07-13 16:02               ` Mark Brown
2015-07-13 16:05               ` Konstantin Ryabitsev [this message]
2015-07-13 16:14                 ` James Bottomley
2015-07-13 18:22                   ` Theodore Ts'o
2015-07-13 16:46                 ` Geert Uytterhoeven
2015-07-13 17:12                   ` josh
2015-07-13 19:37                 ` Jiri Kosina
2015-07-15 18:42           ` Steven Rostedt
2015-07-13 23:25         ` Kees Cook
2015-07-14  7:47           ` James Bottomley
2015-07-14 16:20             ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150713160541.GC15582@gmail.com \
    --to=konstantin@linuxfoundation.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox