Add keyring option #3260
Add keyring option #3260
Conversation
|
This pull request didn't trigger Jenkins as its author isn't in the whitelist. An organization member must perform one of the following:
Those commands are simple Github comments of the format: "jenkins: COMMAND" |
There was a problem hiding this comment.
So this all looks sane to me.
One question I have is whether you expect there to be additional keyring related options. If so then maybe:
lxc.selinux.keyring.context
is the better idea. If not maybe
lxc.selinux.context_keyring
might make more sense:
lxc.selinux.context
lxc.selinux.context_keyring
or even
lxc.selinux.context
lxc.selinux.context.keyring
?
@stgraber, thoughts?
I'm slightly leaning towards this one... |
Thanks for the super fast review ;-) To be honest, I truly am not an expert for that keyring stuff. I just learned about that when debugging my issue :-D One thing that comes to my mind though would be an (probably non-SELinux related) option to completely disable the creation of a new session keyring. To my understanding, if the container is started as a systemd service (for instance), the following happens:
Although this probably doesn't increase performance a lot, in such scenarios the creation of the session keyring by systemd (1.) and lxc (2.) could be spared (afaik systemd offers that option). Other than that, the keyctl system call (http://man7.org/linux/man-pages/man2/keyctl.2.html) offers a lot of options, and there might be some use for some of them. And I guess if one wants to share keys via the session keyring with a container, the disable option might also be useful. But as I said, I just learned about that stuff... |
|
Hm, yeah. Maybe a |
And for the context |
|
On Thu, Jan 30, 2020 at 02:11:28AM -0800, blenk92 wrote:
> Hm, yeah. Maybe a `lxc.keyring.*` namespace might be a good idea. `lxc.keyring.session` which can be set to `1` to create a new session keyring (default) and `0` to not create a new session keyring?
And for the context `lxc.keyring.context` ? Sounds good to me. I can add this if you want...
That's a tough one tbh. We could do:
lxc.keyring.selinux.context
but that would mean duplicating selinux settings. The alternative seems
odd too though:
lxc.selinux.keyring.context
I think
lxc.keyring.selinux.context
feels more natural?
|
Okay, works for me. I'll update my PR then to support both, disabling the session keyring creation ( |
blenk92
force-pushed
the
add-keyring-option
branch
2 times, most recently
from
6c61b6f
to
d28784e
Compare
|
last update was due to spaces vs. tabs for indentaion :-D |
I'm doing a review now but I've just spoken to @stgraber and we think that |
no worries, shouldn't be too much work :-D Actually, I don't think this is what happens. If you look at: The new session keyring is vreated in lxc_setup(). But the selinux context will earliest be set after |
|
I mean, what we can do is set the |
Sounds good. |
blenk92
force-pushed
the
add-keyring-option
branch
from
d28784e
to
f971a46
Compare
okay, I added that and fixed the naming of the config option :-D |
blenk92
force-pushed
the
add-keyring-option
branch
from
f971a46
to
77d2cd8
Compare
|
jenkins: test this please |
|
Compiler seems unhappy :) |
Ah its because |
lxc set's up a new session keyring for every container by default. If executed on an SELinux enabled system, by default, the keyring inherits the label of the creating process. If executed with the currently available SELinux policy, this means that the keyring is labeled with the lxc_t type. Applications inside the container, however, might expect that the keyring is labeled with a certain context (and will fail to access the keyring if it's not explicitly allowed in the global policy). This patch introduces the config option lxc.selinux.context.keyring which enables to specify the label of the newly created keyring. That is, the keyring can be labeled with the label expected by the started application. Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>
lxc set's up a new session keyring for every container by default. There might be valid use-cases where this is not wanted / needed (e.g. systemd by default creates a new session keyring anyway). Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>
Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>
blenk92
force-pushed
the
add-keyring-option
branch
from
77d2cd8
to
ad36e96
Compare
|
jenkins: test this please |
i guess this is not related to my changes? |
Nah, that's not really relevant :) Just means the builder went offline. |
|
Thanks! :) |
Source: meta-virtualization MR: 00000 Type: Integration Disposition: Merged from meta-virtualization ChangeID: b8c810c Description: The added patches allow to set the SELinux context for the session keyring that is created by lxc. In addition it is possible to disable the creation of a new session keyring completely. Upstream PR: lxc/lxc#3260 (merged) If lxc is executed on a SELinux enabled system, these options can be used to assign the expected label to the session keyring. Signed-off-by: Maximilian Blenk <maximilian.blenk@bmw.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
The added patches allow to set the SELinux context for the session keyring that is created by lxc. In addition it is possible to disable the creation of a new session keyring completely. Upstream PR: lxc/lxc#3260 (merged) If lxc is executed on a SELinux enabled system, these options can be used to assign the expected label to the session keyring. Signed-off-by: Maximilian Blenk <maximilian.blenk@bmw.de> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
lxc set's up a new session keyring for every container by default. If executed on an SELinux enabled system, by default, the keyring inherits the label of the creating process. If executed with the
currently available SELinux policy, this means that the keyring is labeled with the lxc_t type. Applications inside the container, however, might expect that the keyring is labeled with a certain context (and will fail to access the keyring if it's not explicitly allowed in the global policy). This patch introduces the config option lxc.selinux.keyring_context which enables to specify the label of the newly created keyring. That is, the keyring can be labeled with the label expected by the started application.