kvm: Add support for capabilities limitation #2222

squall0gd · 2016-02-24T19:03:13Z

By default kvm flavor has got enabled every capability inside pod.
This is normal systemd behavior, when its running as a init process
inside VM. Coreos pod is started by systemd-nspawn, which apply some
initial capabilities by default.

This patch add support for restricted set of capabilities inside rkt-kvm
pod

Cherry pick for tests purposses. It should be merged in pull request rkt#2222 By default kvm flavor has got enabled every capability inside pod. This is normal systemd behavior, when its running as a init process inside VM. Coreos pod is started by systemd-nspawn, which apply some initial capabilities by default. This patch add support for restricted set of capabilities inside rkt-kvm pod

jonboulle · 2016-03-17T14:29:55Z

is this ready for rereview?

squall0gd · 2016-03-17T14:47:45Z

I haven't replied on @woodbor review yet. It's on my roadmap in next 6 work days, so I will refactor this code tomorrow

Cherry pick for tests purposses. It should be merged in pull request rkt#2222 By default kvm flavor has got enabled every capability inside pod. This is normal systemd behavior, when its running as a init process inside VM. Coreos pod is started by systemd-nspawn, which apply some initial capabilities by default. This patch add support for restricted set of capabilities inside rkt-kvm pod

squall0gd · 2016-03-22T08:31:41Z

Review request

borqosky · 2016-03-22T08:45:01Z

stage1/init/kvm/resources.go

+	var caps []types.LinuxCapability
+
+	for _, isolator := range app.Isolators {
+		switch capSet := isolator.Value().(type) {


if there is only one case, if could be better solution than switch- a few lines less

Go compiler requires switch:
build-rkt-1.0.0+git/gopath/src/github.com/coreos/rkt/stage1/init/kvm/resources.go:77: use of .(type) outside type switch

Just one line less.

if capSet, ok := isolator.Value().(types.LinuxCapabilitiesSet); ok { ... }

borqosky · 2016-03-22T09:56:39Z

LGTM

Cherry pick for tests purposses. It should be merged in pull request rkt#2222 By default kvm flavor has got enabled every capability inside pod. This is normal systemd behavior, when its running as a init process inside VM. Coreos pod is started by systemd-nspawn, which apply some initial capabilities by default. This patch add support for restricted set of capabilities inside rkt-kvm pod

squall0gd · 2016-03-24T12:52:17Z

Review request

jonboulle · 2016-03-24T14:59:37Z

stage1/init/common/pod.go


+	if flavor == "kvm" {
+		capabilities := kvm.GetAppCapabilities(app)
+		capabilities = append(capabilities, stdCapabilities...)


I don't actually understand this. This is the list of capabilities that we're applying to a particular app within the pod right? Why would this be any different for the KVM case than for the non-KVM case? And where does nspawn come into it once we're inside the pod?

nspawn is starting with pre-defined capabilities (as an isolation from host). Kvm is starting whole VM with full systemd (which has got every capability and You cannot(and really, You won't ;)) change them). This patch delivers standard capabilities for applications inside pod (so Your pod environment has got every single capability, but Your application don't).

So are you just trying to preserve parity with the fact that a process launched by a systemd-launched-by-systemd-nspawn will have different default capabilities to one launched by systemd-launched-by-lkvm?

If so, wouldn't the better approach be to change the systemd config for the lkvm variant? e.g. https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#CapabilityBoundingSet=

If we use the option systemd-system.conf#CapabilityBoundingSet=, it needs to contain the union of stdCapabilities with the union of caps of each app, because systemd-pid1 would only be able to give the caps from its CapabilityBoundingSet, not more.

rkt does that for systemd-nspawn: it adds --capbility= for each app, as it iterates over the apps and their caps:
https://github.com/coreos/rkt/blob/master/stage1/init/common/pod.go#L706

But I don't know if we need to keep parity between the nspawn and lkvm flavors?

If we want to have the exact same behavior as the nspawn flavor, we should add these capabilities (standard plus the apps') to systemd-system.conf#CapabilityBoundingSet=

Well this configuration file is great, but AFAIK each app inside pod could has got own capabilities configuration, so setting one common file for every app won't work.

@mstachowski Right, but what we're talking about here is the outer bounding set of the pod environment. Then within that, we apply per-app capabilities to each app.

but... @iaguis @alban do we not actually do this part today?!?

There's no "outer bounding set", if apps request capabilities we just give them to them.

Per OOB it seems a bug that we don't set per-app ones - can someone chase that up?

comment captured in #2348

Cherry pick for tests purposses. It should be merged in pull request rkt#2222 By default kvm flavor has got enabled every capability inside pod. This is normal systemd behavior, when its running as a init process inside VM. Coreos pod is started by systemd-nspawn, which apply some initial capabilities by default. This patch add support for restricted set of capabilities inside rkt-kvm pod

jonboulle · 2016-04-13T12:12:53Z

Is this ready for review again?

squall0gd · 2016-04-13T15:11:02Z

@jonboulle yes, it is

iaguis · 2016-04-14T10:30:47Z

stage1/init/common/pod.go

 		"HOME":    "/root",
 	}
+
+	// List of default capabilities inside systemd-nspawn pod is available


The list of default...

iaguis · 2016-04-14T10:31:15Z

Some nits but after those LGTM

squall0gd · 2016-04-14T11:27:05Z

@iaguis done

iaguis · 2016-04-14T11:54:00Z

stage1/init/common/pod.go

+// GetAppCapabilities is a filter which returns a string slice of valid Linux capabilities
+// It requires list of available isolators
+func GetAppCapabilities(isolators types.Isolators) []string {
+


Can you remove this line?

iaguis · 2016-04-14T12:10:08Z

stage1/init/common/pod.go

+	return caps
+}
+
+// parseLinuxCapabilitySetToString parses a LinuxCapabilitiesSet into string slice


Last thing, outdated docstring :D

The test passed before updating the docstring so we can merge it right-away once it's updated.

iaguis · 2016-04-14T12:29:34Z

LGTM

By default kvm flavor has got enabled every capability inside pod. This is normal systemd behavior, when its running as a init process inside VM. Coreos pod is started by systemd-nspawn, which apply some initial capabilities by default. This patch add support for restricted set of capabilities inside rkt-kvm pod

iaguis added kind/enhancement component/stage1 technology/kvm priority/P1 area/security needs/some-changes labels Mar 4, 2016

iaguis added this to the v1.2.0 milestone Mar 4, 2016

iaguis modified the milestones: v1.3.0, v1.2.0 Mar 18, 2016

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch 2 times, most recently from 0a325f8 to ac2102c Compare March 22, 2016 08:11

borqosky reviewed Mar 22, 2016
View reviewed changes

jonboulle added needs/review and removed needs/some-changes labels Mar 22, 2016

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch from ac2102c to 169f391 Compare March 23, 2016 08:20

jonboulle reviewed Mar 24, 2016
View reviewed changes

jonboulle removed the needs/review label Apr 4, 2016

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch 2 times, most recently from b181b88 to 3bc66c1 Compare April 13, 2016 15:10

alban added needs/review and removed needs/some-changes labels Apr 14, 2016

iaguis reviewed Apr 14, 2016
View reviewed changes

iaguis added needs/some-changes and removed needs/review labels Apr 14, 2016

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch from 3bc66c1 to ee2ea7a Compare April 14, 2016 11:26

iaguis reviewed Apr 14, 2016
View reviewed changes

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch from ee2ea7a to d7e2254 Compare April 14, 2016 12:09

iaguis reviewed Apr 14, 2016
View reviewed changes

iaguis added reviewed/lgtm and removed needs/some-changes labels Apr 14, 2016

squall0gd force-pushed the mstachow/rkt_add_default_capabilities branch from d7e2254 to d66fa61 Compare April 14, 2016 12:39

iaguis merged commit 94b6283 into rkt:master Apr 14, 2016

squall0gd deleted the mstachow/rkt_add_default_capabilities branch April 14, 2016 12:41

Uh oh!

kvm: Add support for capabilities limitation #2222

kvm: Add support for capabilities limitation #2222

Uh oh!

Conversation

squall0gd commented Feb 24, 2016

Uh oh!

jonboulle commented Mar 17, 2016

Uh oh!

squall0gd commented Mar 17, 2016

Uh oh!

squall0gd commented Mar 22, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

borqosky commented Mar 22, 2016

Uh oh!

squall0gd commented Mar 24, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonboulle commented Apr 13, 2016

Uh oh!

squall0gd commented Apr 13, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iaguis commented Apr 14, 2016

Uh oh!

squall0gd commented Apr 14, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iaguis commented Apr 14, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants