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

required key not available in docker container #128

Open
kzidane opened this issue Mar 21, 2019 · 7 comments

Comments

Projects
None yet
6 participants
@kzidane
Copy link

commented Mar 21, 2019

If I mount an encrypted folder into a docker container, it seems I can't write to that folder from within the container per the following:

$ fscrypt status /home/kzidane/
"/home/kzidane/" is encrypted with fscrypt.

Policy:   37064e515e94c9a0
Unlocked: Yes

Protected with 1 protector:
PROTECTOR         LINKED   DESCRIPTION
2fe3444e16452da0  Yes (/)  login protector for kzidane
$ docker run -it --rm -v/home/kzidane:/root/tmp ubuntu bash -c 'echo foo > /root/tmp/foo'
bash: /root/tmp/foo: Required key not available

Any way to fix this by chance?

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.10
Release:        18.10
Codename:       cosmic

$ fscrypt --version
fscrypt - A tool for managing Linux filesystem encryption

Version:
  v0.2.4-24-g8956903

Compiled:
  2019-03-05 11:13:16 -0500 EST

Author:
  Joe Richey <joerichey@google.com>

Copyright:
  Copyright 2017 Google, Inc.

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.


$ docker --version
Docker version 18.09.3, build 774a1f4
@nawarnoori

This comment has been minimized.

Copy link

commented Apr 8, 2019

I ran into the same problem. Could a maintainer please comment?

@josephlr

This comment has been minimized.

Copy link
Member

commented Apr 8, 2019

Sorry for the delay in replying, I just got back from leave.

@kzidane @nawarnoori so the main issue here is that kernel namespaces (which containers use) do not play nicely with the kernel keyrings (which the fscrypt kernel component uses for key management). I've been looking into this problem for awhile, mainly on how to fix this without modifying the kernel.

I can start experimenting with docker configs and kernel configs to make this work. But actually fixing this problem will require more extensive changes to the kernel.

There are a bunch of relevant kernel patchsets in progress to actually fix this, but they will take awhile to be merged and filter down to most users of Linux.

@williamjieh

This comment has been minimized.

Copy link

commented Jun 17, 2019

I've installed fscrypt version 0.2.0, how can I apply this patch:
https://patchwork.kernel.org/cover/10881911/
Do I need to modify the source code and build it myself?

@josephlr

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

I've installed fscrypt version 0.2.0, how can I apply this patch:
https://patchwork.kernel.org/cover/10881911/
Do I need to modify the source code and build it myself?

Yes, you would have to rebuild the kernel. I would use the v6 patchset. @ebiggers has a patchset for this tool that will support these new policies. I need a good way to test this with the CI before merging it, but hopefully the patches will get merged upstream soon.

@ebiggers

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

I've installed fscrypt version 0.2.0, how can I apply this patch:
https://patchwork.kernel.org/cover/10881911/
Do I need to modify the source code and build it myself?

Yes, and in addition to building a custom kernel you'd also need to build your own version of the fscrypt tool from my experimental branch, which is linked to from the kernel patchset's cover letter. Then you'd need to delete your encrypted directories and re-create them using the new encryption policy version. (The new kernel API works with existing encrypted directories too, but my changes to the fscrypt tool don't take advantage of that yet.) And my changes to the fscrypt tool are still experimental and might contain bugs. But if you understand all this and would like to help test it, please go ahead; it would be appreciated.

I've still been pushing to get the kernel patches merged, but they still need review and sign off from the other fscrypt (kernel-side) maintainers, and we all tend to be very busy on other projects. It would also be helpful if more people would participate in the discussion on the linux-fscrypt mailing list.

@ramcq

This comment has been minimized.

Copy link

commented Jun 27, 2019

At present because the kernel keyring is not currently namespaced, it is filtered out inside the docker container. So for the time being, this can also be worked around with a custom seccomp policy that permits the request_key syscall inside the container. Save https://gist.github.com/ramcq/f95bc369cd46905d7e2598c1dcf16155#file-seccomp-with-request_key-json-L246 to your filesystem and add --security-opt seccomp:seccomp-with-request_key-json to docker run parameters.

@ramcq

This comment has been minimized.

Copy link

commented Jun 27, 2019

At present because the kernel keyring is not currently namespaced, it is filtered out inside the docker container. So for the time being, this can also be worked around with a custom seccomp policy that permits the request_key syscall inside the container. Save https://gist.github.com/ramcq/f95bc369cd46905d7e2598c1dcf16155#file-seccomp-with-request_key-json-L246 to your filesystem and add --security-opt seccomp:seccomp-with-request_key-json to docker run parameters.

So I found I had a separate problem with my container images that was causing me not to be able to access my ~ - but when you run your container with --priveleged then it should have keyring access. It's likely that --priveleged setting seccomp to unconfined is what allows the keyring to work, but I am no longer certain that request_key alone is sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.