Feature #15798

Jenkins access for new FT members

Added by segfault 2018-08-16 19:02:44 . Updated 2018-11-20 17:04:20 .

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

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

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

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2018-08-19 16:10:49

  • 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 2018-08-19 16:12:03

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

#3 Updated by intrigeri 2018-08-19 16:12:58

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

#4 Updated by intrigeri 2018-08-19 16:13:18

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

#5 Updated by intrigeri 2018-08-19 16:13:28

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

#6 Updated by intrigeri 2018-09-01 10:31:11

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

#7 Updated by intrigeri 2018-09-04 13:03:11

  • 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 2018-09-14 08:38:15

  • has duplicate Feature #15897: Make our CI useful for more people added

#9 Updated by intrigeri 2018-09-25 08:45:57

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

#10 Updated by intrigeri 2018-09-25 08:47:39

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 Feature #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 2018-09-25 08:55:51

#12 Updated by intrigeri 2018-09-25 08:59:01

> 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 2018-09-25 09:16:45

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 Feature #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 Feature #11344 first.

#14 Updated by intrigeri 2018-09-25 09:16:55

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

#15 Updated by intrigeri 2018-09-25 09:17:45

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

#16 Updated by intrigeri 2018-09-25 09:17:47

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

#17 Updated by intrigeri 2018-09-25 09:17:51

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

#18 Updated by intrigeri 2018-09-25 09:17:57

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

#19 Updated by intrigeri 2018-09-25 09:18:06

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

#20 Updated by intrigeri 2018-09-25 09:19:07

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 2018-09-25 09:19:33

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

Can you please sanity check my plan?

#22 Updated by intrigeri 2018-09-25 09:23:09

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

#23 Updated by intrigeri 2018-09-25 09:23:15

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

#24 Updated by groente 2018-09-25 10:26:37

  • 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 2018-09-26 06:08:46

> 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 2018-09-26 10:10:02

  • 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 2018-09-26 16:17:49

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 (Feature #15981)
  • wrt. allowing to push branches that will trigger Jenkins jobs:

#28 Updated by intrigeri 2018-10-12 12:02:04

#29 Updated by intrigeri 2018-10-22 09:59:52

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

#30 Updated by intrigeri 2018-11-19 10:01:56

  • Target version deleted (Tails_3.11)

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

#31 Updated by intrigeri 2018-11-20 16:55:45

  • 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 2018-11-20 17:03:15

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

#33 Updated by intrigeri 2018-11-20 17:04:20

  • 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”).