Project

General

Profile

Feature #15798

Jenkins access for new FT members

Added by segfault 11 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Continuous Integration
Target version:
Start date:
09/26/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

What would it take to give hefee, kibi, lamby and segfault access to Jenkins?


Related issues

Related to Tails - Feature #15981: Define security policy for access that gives arbitrary code execution on the Tails infrastructure Resolved 09/26/2018
Duplicated by Tails - Feature #15897: Make our CI useful for more people Duplicate 09/02/2018
Blocked by Tails - Feature #15975: Give commit access to kibi and segfault Resolved 09/25/2018
Blocked by Tails - Feature #11344: Enable libvirt's AppArmor support on lizard Resolved 04/13/2016
Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) Confirmed 06/30/2017

History

#1 Updated by intrigeri 11 months ago

  • Category set to Continuous Integration

groente, let's discuss this during our next sprint (tentatively scheduled in a bit more than a month). In passing, it might be that one of the discussions ("Fix the Release Management situation") I'll propose for the summit agenda leads us to conclusions that will simplify this very discussion a great lot; or not. We'll see.

#2 Updated by intrigeri 11 months ago

  • Blocks Feature #13242: Core work: Sysadmin (Maintain our already existing services) added

#3 Updated by intrigeri 11 months ago

  • Related to Bug #10068: Upgrade to Jenkins 2.x, using upstream packages added

#4 Updated by intrigeri 11 months ago

  • Related to Feature #15502: Update Jenkins modules: 2018Q2 → 2018Q3 edition added

#5 Updated by intrigeri 11 months ago

  • Related to Feature #15503: Update Jenkins modules: 2018Q4 → 2019Q1 edition added

#6 Updated by intrigeri 11 months ago

  • Subject changed from Jenkins access for kibi and segfault to Jenkins access for new FT members
  • Description updated (diff)

#7 Updated by intrigeri 11 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

Status update:

  • I've put things in motion for kibi and segfault, in a way that would work (if accepted by the relevant authorities™) with our current setup. Next steps are:
    • Wait for a decision on tails@ (Sept 18).
    • Once that's done, wait until kibi and segfault satisfy the relevant security policy.
  • For hefee and lamby, I think this is less urgent and I doubt we can do it with our current setup beyond giving them access to the web interface. So the outcome of the sysadmin sprint would be:
    • Find out what's at stake if we give them access to the web interface and if relevant, ask tails@ if that's OK.
    • Define how our setup needs to be changed in order to allow hefee, lamby, and possibly more people to send branches to Jenkins.

#8 Updated by intrigeri 10 months ago

  • Duplicated by Feature #15897: Make our CI useful for more people added

#9 Updated by intrigeri 10 months ago

  • Blocked by Feature #15975: Give commit access to kibi and segfault added

#10 Updated by intrigeri 10 months ago

intrigeri wrote:

Status update:

  • I've put things in motion for kibi and segfault, in a way that would work (if accepted by the relevant authorities™) with our current setup. Next steps are:
    • Wait for a decision on tails@ (Sept 18).
    • Once that's done, wait until kibi and segfault satisfy the relevant security policy.

We've made progress, next steps are now tracked on #15975.

  • For hefee and lamby, I think this is less urgent and I doubt we can do it with our current setup beyond giving them access to the web interface. So the outcome of the sysadmin sprint would be:
    • Find out what's at stake if we give them access to the web interface and if relevant, ask tails@ if that's OK.
    • Define how our setup needs to be changed in order to allow hefee, lamby, and possibly more people to send branches to Jenkins.

Let's discuss/research that this week.

#11 Updated by intrigeri 10 months ago

#12 Updated by intrigeri 10 months ago

Find out what's at stake if we give them access to the web interface and if relevant, ask tails@ if that's OK.

Next step here (since we cannot trust Jenkins itself): check consequences of having access to the jenkins user on our Jenkins master and its workers. Note that the jenkins user has sudo permissions on all Jenkins workers.

Define how our setup needs to be changed in order to allow hefee, lamby, and possibly more people to send branches to Jenkins.

Gitolive v3 access rules can use regexp to match refs (http://gitolite.com/gitolite/conf/#access-rules) so once we self-host our master Git repo, I propose we give hefee and lamby access to their own branch namespace (hefee/*, lamby/*), which will allow them to send branches to Jenkins without any change to our setup. Gitolite v2 has a similar feature so we're not blocked by the upgrade to v3 :)

#13 Updated by intrigeri 10 months ago

intrigeri wrote:

Find out what's at stake if we give them access to the web interface and if relevant, ask tails@ if that's OK.

Next step here (since we cannot trust Jenkins itself): check consequences of having access to the jenkins user on our Jenkins master and its workers.

I've looked at sudo, SSH and Git credentials and apart of access to public info:

  • root on all Jenkins workers => potentially escape from VM, would be mitigated by #11344
  • RW config of Jenkins (jobs, global config)
  • R test suite shared secrets

I think none of this is a big deal except I want to do #11344 first.

#14 Updated by intrigeri 10 months ago

  • Related to Feature #11344: Enable libvirt's AppArmor support on lizard added

#15 Updated by intrigeri 10 months ago

  • Related to deleted (Bug #10068: Upgrade to Jenkins 2.x, using upstream packages)

#16 Updated by intrigeri 10 months ago

  • Related to deleted (Feature #15503: Update Jenkins modules: 2018Q4 → 2019Q1 edition)

#17 Updated by intrigeri 10 months ago

  • Related to deleted (Feature #15502: Update Jenkins modules: 2018Q2 → 2018Q3 edition)

#18 Updated by intrigeri 10 months ago

  • Related to deleted (Feature #11344: Enable libvirt's AppArmor support on lizard)

#19 Updated by intrigeri 10 months ago

  • Blocked by Feature #11344: Enable libvirt's AppArmor support on lizard added

#20 Updated by intrigeri 10 months ago

Note that I'm not blocking on running a Jenkins version with security support from upstream, hence the analysis based on the fact one can escalate from "access to the Jenkins web UI" to "execute arbitrary code as the Jenkins user".

#21 Updated by intrigeri 10 months ago

  • Assignee changed from intrigeri to groente
  • QA Check set to Ready for QA

Can you please sanity check my plan?

#22 Updated by intrigeri 10 months ago

  • Blocks deleted (Feature #13242: Core work: Sysadmin (Maintain our already existing services))

#23 Updated by intrigeri 10 months ago

  • Blocks Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#24 Updated by groente 10 months ago

  • Assignee changed from groente to intrigeri
  • QA Check changed from Ready for QA to Info Needed

I'm wondering whether escalation to root on the jenkins workers would also open up the possibility to do arp-spoofing on lizard's internal network? That would open up another can of worms, but I know too little about kvm/qemu networking to say how realistic this scenario is.

#25 Updated by intrigeri 10 months ago

I'm wondering whether escalation to root on the jenkins workers would also open up the possibility to do arp-spoofing on lizard's internal network?

Probably because I don't think we've ever enabled libvirt's protections against such attacks (and I doubt they're compatible with how we manage our firewall); I'll take a look.

That would open up another can of worms

Interesting, indeed. I don't know how much of our stuff trusts that internal network but surely some does. I'll look into it.

#26 Updated by intrigeri 10 months ago

  • QA Check deleted (Info Needed)

intrigeri wrote:

I'm wondering whether escalation to root on the jenkins workers would also open up the possibility to do arp-spoofing on lizard's internal network?

Probably because I don't think we've ever enabled libvirt's protections against such attacks (and I doubt they're compatible with how we manage our firewall); I'll take a look.

I've enabled the clean-traffic ebtables filter (https://libvirt.org/formatnwfilter.html) for all VMs so we should now be good on this front.

#27 Updated by intrigeri 10 months ago

Last remaining steps:

  • wrt. giving access to the Jenkins web UI:
    • hefee, kibi, lamby, segfault: give access as soon as they meet the relevant security policy (#15981)
  • wrt. allowing to push branches that will trigger Jenkins jobs:
    • hefee, lamby: this can now be done via the Gitolite config once they meet the relevant security policy (#15981)
    • kibi: #15981 and then #15975 or #14588, whichever happens first
    • segfault: done

#28 Updated by intrigeri 9 months ago

#29 Updated by intrigeri 9 months ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#30 Updated by intrigeri 8 months ago

  • Target version deleted (Tails_3.11)

I'll complete this once hefee is done with his security policy compliance checks.

#31 Updated by intrigeri 8 months ago

  • Target version set to Tails_3.11

intrigeri wrote:

I'll complete this once hefee is done with his security policy compliance checks.

He's done! :)

#32 Updated by intrigeri 8 months ago

  • Related to Feature #15981: Define security policy for access that gives arbitrary code execution on the Tails infrastructure added

#33 Updated by intrigeri 8 months ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 50 to 100

All FT members now have access to the web UI and can submit branches (either in their own namespace or anywhere, depending on whether they have the "commit bit").

Also available in: Atom PDF