Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

daemon: add a flag to override the default seccomp profile #26276

Merged
merged 1 commit into from
Nov 4, 2016

Conversation

runcom
Copy link
Member

@runcom runcom commented Sep 2, 2016

Supersedes #24221

Introduce /etc/docker/seccomp.json as per discussion in #24221

/cc @justincormack @cpuguy83 @LK4D4 @jfrazelle @cyphar @rhatdan

Signed-off-by: Antonio Murdaca runcom@redhat.com

@justincormack
Copy link
Contributor

@runcom accidentally typing systemd in the issue title!

I will summarise the discussion in the previous issue.

@runcom
Copy link
Member Author

runcom commented Sep 2, 2016

@runcom accidentally typing systemd in the issue title!

I swear it was a mistake! 😄

@runcom runcom changed the title [WIP] systemd wide default seccomp profile [WIP] system wide default seccomp profile Sep 2, 2016
@runcom
Copy link
Member Author

runcom commented Sep 2, 2016

/cc @rhatdan @jeremyeder

func (daemon *Daemon) setupSeccompProfile() error {
b, err := ioutil.ReadFile(seccompProfilePath)
if err != nil {
// TODO(runcom): generate a default seccomp profile if system wide isn't present?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@justincormack wdyt? Will be okay to bail out if no seccomp json in there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are going to have an internal one, then we should check if the path is "" and use the default. If the admin specified seccomppath and the path does not exist, we should error out.

Copy link
Member Author

@runcom runcom Sep 2, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we're going to override the default with a flag in the daemon given people/admin/distros can already override the default at /etc/docker/seccomp.json

I believe this was the intention of @justincormack as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently I don't think we provide ways to override a lot of the file locations for things. I would think that if we provided a way to override the /etc/docker location in future, this would then look in that directory, but I don't think it needs to be explicitly overrideable other than that.

Copy link
Member Author

@runcom runcom Sep 2, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, what about my question in the comment in the code instead? @justincormack

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also causing CI to fail because on integration tests start the daemon doesn't come up (not /etc/docker/seccomp.json)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should generate one either, as that would mean embedding the json in the binary which seems gross.

Does the CI use make install? In which case can fix that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotcha, I'll fix it by installing a profile under /etc/docker/seccomp.json

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it doesn't seem to be using make install, I hacked up something to install the profile in /etc/docker, maybe @tianon can guide me :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can probably copy the default.json in bundles/VERSION/bundle as we do now for the binaries, I don't know really, it's working now but waiting for any input

@runcom runcom force-pushed the seccomp-conf branch 6 times, most recently from fbd486b to 58bc5d5 Compare September 3, 2016 11:04
@runcom runcom added this to the 1.13.0 milestone Sep 3, 2016
@runcom runcom force-pushed the seccomp-conf branch 4 times, most recently from 90bae56 to 02a6ee0 Compare September 3, 2016 14:21
@@ -16,6 +16,10 @@ if [ "$(go env GOOS)" = 'windows' ]; then
return
fi

if [ ! -x "/etc/docker/seccomp.json" ]; then
install_seccomp "$base/../../profiles/seccomp/default.json"
Copy link
Member Author

@runcom runcom Sep 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tianon PTAL this is a hack to make tests running - not sure where should this go honestly..

also @jhowardmsft win2lin fails but I wasn't be able to understand why...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this isn't safe to include here (since these scripts are supposed to be runnable on your host, too). Couldn't/shouldn't the default profile path be a daemon flag/config option? (esp. so that the tests could point directly to the copy in the repo)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't/shouldn't the default profile path be a daemon flag/config option? (esp. so that the tests could point directly to the copy in the repo)

There has been some discussion around this in #24221 and that was how this feature was initially proposed. This PR basically follows this specific comment #24221 (comment) and so, I think it isn't really ok to have a daemon flag/config. I'm still open to have this though. /cc @justincormack

@runcom
Copy link
Member Author

runcom commented Sep 6, 2016

@justincormack PTAL

@runcom runcom changed the title [WIP] system wide default seccomp profile [RFC] system wide default seccomp profile Sep 6, 2016
@thaJeztah
Copy link
Member

ping @runcom looks like the API change https://github.com/docker/docker/pull/26276/files#r82990210 was not documented (think it's an API change 😄)

Can you add it to the API changes (https://github.com/docker/docker/blob/master/docs/reference/api/docker_remote_api.md#v125-api-changes), and update the API reference docs (https://github.com/docker/docker/blob/master/docs/reference/api/docker_remote_api_v1.25.md) if needed?

also ping @albers @sdurrheimer for the completion scripts :)

@runcom
Copy link
Member Author

runcom commented Nov 4, 2016

@thaJeztah sure

@vikstrous
Copy link
Contributor

FYI This is a backwards incompatible API change that broke installing UCP 2.0.0 on docker master.

@runcom
Copy link
Member Author

runcom commented Nov 6, 2016

@vikstrous could you open an issue? I'll take care of fixing the backwards compatibility, though, if you use api version 1.24 everything should work

@vikstrous
Copy link
Contributor

Sure: #28113

dnephin pushed a commit to dnephin/docker that referenced this pull request Apr 17, 2017
daemon: add a flag to override the default seccomp profile
thaJeztah added a commit to thaJeztah/docker that referenced this pull request Aug 7, 2021
Commit b237189 implemented an option to
set the default seccomp profile in the daemon configuration. When that PR
was reviewed, it was discussed to have the option accept the path to a custom
profile JSON file; moby#26276 (comment)

However, in the implementation, the special "unconfined" value was not taken into
account. The "unconfined" value is meant to disable seccomp (more factually:
run with an empty profile).

While it's likely possible to achieve this by creating a file with an an empty
(`{}`) profile, and passing the path to that file, it's inconsistent with the
`--security-opt seccomp=unconfined` option on `docker run` and `docker create`,
which is both confusing, and makes it harder to use (especially on Docker Desktop,
where there's no direct access to the VM's filesystem).

This patch adds the missing check for the special "unconfined" value.

Co-authored-by: Tianon Gravi <admwiggin@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
docker-jenkins pushed a commit to docker-archive/docker-ce that referenced this pull request Aug 11, 2021
Commit b237189 implemented an option to
set the default seccomp profile in the daemon configuration. When that PR
was reviewed, it was discussed to have the option accept the path to a custom
profile JSON file; moby/moby#26276 (comment)

However, in the implementation, the special "unconfined" value was not taken into
account. The "unconfined" value is meant to disable seccomp (more factually:
run with an empty profile).

While it's likely possible to achieve this by creating a file with an an empty
(`{}`) profile, and passing the path to that file, it's inconsistent with the
`--security-opt seccomp=unconfined` option on `docker run` and `docker create`,
which is both confusing, and makes it harder to use (especially on Docker Desktop,
where there's no direct access to the VM's filesystem).

This patch adds the missing check for the special "unconfined" value.

Co-authored-by: Tianon Gravi <admwiggin@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 68e96f88ee1598563a66a1f53b8844291423fc88
Component: engine
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants