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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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

On Mon, 2015-07-13 at 12:05 -0400, Konstantin Ryabitsev wrote:
> 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.

If I'm away and not doing any activity, it's only going to be in trees
that are basing on mine, so not really wide dissemnation

> 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.

How multiple developers wish to work on the same repo is largely up to
them.  I could design a work flow that would detect injections without
2fa, but if they choose another way, it's fine by me.

> 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.

Well, that's not what I do: I have one master tree and I work from that.

> 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.

It's possible, but it's a really short window to trick an agent.  The
default of ssh is no agent forwarding, anyway.

> - Many 0-days in client tools allow full access to local content, but
>   not necessarily an ability to execute arbitrary commands.

I'm not sure I get this: you mean client tools may compromise my ssh
keys?

> - 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!).

Well, not me ... I use a mirror between my server and my laptop for
that.

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

So: I admit that if I'm careless, 2fa helps protect everyone else.
However, I think you can see that if I'm careful (as I claim I am) 2fa
doesn't buy me much.

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]