From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] dev/maintainer workflow security
Date: Mon, 13 Jul 2015 16:39:20 +0100 [thread overview]
Message-ID: <1436801960.6901.19.camel@HansenPartnership.com> (raw)
In-Reply-To: <20150713140752.GA15582@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]
On Mon, 2015-07-13 at 10:07 -0400, Konstantin Ryabitsev wrote:
> On Mon, Jul 13, 2015 at 10:32:06AM +0200, Jiri Kosina wrote:
> > If the credentials can be used both to push to ra.kernel.org and to access
> > your "local" copy of the GIT repo (on your notebook / desktop / storage),
> > I can just push the malicious commit (*) to both repos and you might not
> > notice immediately (because you wouldn't get non-fast-forward hint from
> > git).
>
> This is mitigated somewhat by existing 2-factor mechanisms placed on
> select git repositories.
>
> https://korg.wiki.kernel.org/userdoc/gitolite_2fa
>
> To successfully attack in this manner, you would need to push to
> gitolite.kernel.org from an IP address that's been previously
> 2fa-validated by the developer.
>
> Which brings me around to grumbling a bit -- since we've made 2-factor
> auth available, only 30 people have set up a token[*] (not even 10% of all
> account holders) and only 25 repositories/subdirs have a 2fa requirement
> on them, out of 450 defined.
>
> 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.
James
> Best,
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-07-13 15:39 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 [this message]
2015-07-13 16:02 ` Mark Brown
2015-07-13 16:05 ` Konstantin Ryabitsev
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=1436801960.6901.19.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=konstantin@linuxfoundation.org \
--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