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

[RFE] Restricting access to physical memory #1158

Closed
w2vy opened this issue Aug 10, 2023 · 3 comments
Closed

[RFE] Restricting access to physical memory #1158

w2vy opened this issue Aug 10, 2023 · 3 comments
Labels
kind/feature A feature request

Comments

@w2vy
Copy link

w2vy commented Aug 10, 2023

Current situation

The kernel has CONFIG_PROC_KCORE enabled so that all physical memory can be examined

Impact

If sensitive data or keys to run an encrypted container are used they will be present in memory allowing anyone with access to the to capture the keys

Ideal future situation

Can flatcar run with /pro/kcore disabled? Also it might be valuable to disable /proc/[pid]/mem which also provides access to a single process's memory (kernel patch needed)

Implementation options

Also would insure CONFIG_CROSS_MEMORY_ATTACH=n as well as CONFIG_STRICT_DEVMEM=y and maybe some others

Additional information

Why am I asking? All existing system assume every user trusts the root user when in fact we often don't know them.
Closing direct memory access eliminates the need to trust them.

They can kill the system but that is very different from compromising sensitive data

@w2vy w2vy added the kind/feature A feature request label Aug 10, 2023
@jepio
Copy link
Member

jepio commented Aug 10, 2023

Have you looked into kernel lockdown (https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)? That has a confidentiality mode that you can enable and then /proc/kcore access is disabled (https://elixir.bootlin.com/linux/latest/source/fs/proc/kcore.c#L590).

Also it might be valuable to disable /proc/[pid]/mem which also provides access to a single process's memory (kernel patch needed)

We generally tend to not carry out of tree patches that change behavior from upstream.

Why am I asking? All existing system assume every user trusts the root user when in fact we often don't know them.
Closing direct memory access eliminates the need to trust them.

They can kill the system but that is very different from compromising sensitive data

As someone working on "confidential containers" I would say: if you want full confidentiality you need to run your containers with something like Kata containers and using confidential computing hardware to get the guarantees you mention.

@w2vy
Copy link
Author

w2vy commented Aug 11, 2023

Is "confidential computing hardware" provided by CPUs with TPM 1.x or TPM 2? Or is there more to it? Going to learn more about Kata now Thanks!

@jepio
Copy link
Member

jepio commented Aug 11, 2023

No - TPM is not enough. This is about technologies such as AMD SEV-SNP or Intel TDX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A feature request
Projects
None yet
Development

No branches or pull requests

2 participants