On 11/29/21 09:46, James Bottomley wrote:
On Mon, 2021-11-29 at 15:22 +0100, Christian Brauner wrote:
On Mon, Nov 29, 2021 at 09:10:29AM -0500, James Bottomley wrote:
On Mon, 2021-11-29 at 08:53 -0500, Stefan Berger wrote:
On 11/29/21 07:50, James Bottomley wrote:
On Sun, 2021-11-28 at 22:58 -0600, Serge E. Hallyn wrote:
On Sat, Nov 27, 2021 at 04:45:49PM +0000, James Bottomley
wrote:
Currently we get one entry in the IMA log per unique file
event. So, if you have a measurement policy and it
measures a particular binary it will not get measured again
if it is subsequently executed. For Namespaced IMA, the
correct behaviour seems to be to log once per inode per
namespace (so every unique execution in a namespace gets a
separate log entry). Since logging once per inode per
namespace is
I suspect I'll need to do a more in depth reading of the
existing code, but I'll ask the lazy question anyway (since
you say "the correct behavior seems to be") - is it actually
important that files which were appraised under a parent
namespace's policy already should be logged again?
I think so. For a couple of reasons, assuming the namespace
eventually gets its own log entries, which the next incremental
patch proposed to do by virtualizing the securityfs
entries. If you don't do this:
To avoid duplicate efforts, an implementation of a virtualized
securityfs is in this series here:
https://github.com/stefanberger/linux-ima-namespaces/commits/v5.15%2Bimans.20211119.v3
It starts with 'securityfs: Prefix global variables with
secruityfs_'
That's quite a big patch series. I already actually implemented
this as part of the RFC for getting the per namespace measurement
log. The attached is basically what I did.
Most of the time we don't require namespacing the actual virtualfs
file, because it's world readable. IMA has a special requirement
in this regard because the IMA files should be readable (and
writeable when we get around to policy updates) by the admin of the
namespace but their protection is 0640 or 0440. I thought the
simplest solution would be to make an additional flag that coped
with the permissions and a per-inode flag way of making the file as
"accessible by userns admin". Doing something simple like this
gives a much smaller diffstat:
That's a NAK from me. Stefan's series might be bigger but it does
things correctly. I appreciate the keep it simple attitude but no. I
won't speciale-case securityfs or similar stuff in core vfs helpers.
Well, there's a reason it's an unpublished patch. However, the more
important point is that namespacing IMA requires discussion of certain
points that we never seem to drive to a conclusion. Using the akpm
method, I propose simple patches that drive the discussion. I think
the points are:
[...]
And, of course, the fun ones we're coming to.
1. Given that the current keyring namespacing doesn't give access to
the system keyrings, how do we get per-namespace access for
.ima/_ima system keyrings given that the namespace admin is going to
want to set their own key for appraisal?
2. What mechanism should we use for .ima/_ima key setting? The current
mechanism is must be signed by a key in the system keyrings sounds
appropriate, but is problematic given most system owners don't
actually have any private keys for keys in the system keyrings.
Hopefully the MoK keyring patches will help us have an easier
approach to this.
The approach we took in the previous implementation was to support BYOK
(bring your own key) for every container. The (trusted) container
runtime has to do what dracut would typically do, namely create the
keyrings and load the keys onto it.
The container runtime would
1a) expect keys to be found inside a container's filesystem at the usual
location (/etc/keys/ima) but then also allow for a CA key that is used
to verify the signature of those keys; that CA key is typically baked
into the Linux kernel when .ima is to be used, but for containers and
BYOK it's an additional file in the container's filesystem
1b) passing in keys via command line should be possible as well but
that's an implementation detail
2) container runtime sets up either a restricted keyring [
https://elixir.bootlin.com/linux/latest/source/Documentation/crypto/asymmetric-keys.rst#L359
] if that CA key is found in the filesystem or a 'normal' keyring. The
container runtime then loads the keys onto that keyring; call that
keyring '.ima' or '_ima' for as long as the kernel knows what keyring to
search for. We created that keyring under a session keyring. With the
user namespace isolation and keyrings support in the user namespace the
isolation of the IMA related keyrings between different user namespaces
should be possible.
The same would be done for the IMA policy where the container runtime
also needs to do some work that usually dracut would do:
- expect the IMA policy for the container at the usual location
(/etc/ima/ima-policy) and load it into the container's 'securityfs'
policy file
Stefan
