Containers don't handle keys, but should they?
Am I right in thinking that a UID in one container is not necessarily equivalent to the numerically equivalent UID in another container?
If that's the case then the key management code will need changing as it assumes all keys belonging to one numeric UID eat out of the same quota and the numeric UIDs are used in security checks.
Furthermore, processes in one container can access keys created by a process in another container by ID. Is this desirable or not?
David
A message that is not in the archive (sent off-list or not yet received): [email protected]
yes. If I understand correct key management requires containerization (i.e. "virtualization") as well other subsystems like IPC dealing with IDs.
Processes from one container should not be able to access keys from another container.
Quoted 16 lines · David Howells
Am I right in thinking that a UID in one container is not necessarily equivalent to the numerically equivalent UID in another container?
If that's the case then the key management code will need changing as it assumes all keys belonging to one numeric UID eat out of the same quota and the numeric UIDs are used in security checks.
Furthermore, processes in one container can access keys created by a process in another container by ID. Is this desirable or not?
David
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers
Quoted 4 lines · David Howells
Am I right in thinking that a UID in one container is not necessarily equivalent to the numerically equivalent UID in another container?
Quoted 8 lines
If that's the case then the key management code will need changing as it assumes all keys belonging to one numeric UID eat out of the same quota and the numeric UIDs are used in security checks.
Furthermore, processes in one container can access keys created by a process in another container by ID. Is this desirable or not?
David
Yes, the confusion comes from using the word 'container' which doesn't really exist. The user namespaces (CLONE_NEWUSER) are what provide separate of uids. We want uid 5 in one user namespace to have completely separate set of keys from uid 5 in another user namespace.
This isn't yet a crucial thing to get right as the user namespaces are only partially implemented, but it's certainly a good thing to be looking at and fix when convenient to do so. It looks like maybe just adding a struct user_namespace * to a struct key should suffice.
-serge
A message that is not in the archive (sent off-list or not yet received): 20080314145447.GG9741-6s5zFf/[email protected]
Quoted 2 lines · Serge E. Hallyn
It looks like maybe just adding a struct
user_namespace* to a struct key should suffice.
That's not quite sufficient. The per-UID key_user structs also need to be differentiated. Unfortunately, I can't just merge it into user_struct as I then end up with a reference loop user_struct -> uid_keyring -> user_struct.
Rooting the key_user trees in user_namespace will probably do the trick.
A couple of questions:
(1) A process may inherit a session keyring over clone(). Should this be discarded if CLONE_NEWUSER is set? Or would I need to copy it?
(2) In a recent patch, I've given the root user its own quota limits. Is UID 0 always the root user in any container? Or would it make more sense just to scrap the per-root quota limits?
David
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · David Howells
Quoted 2 lines · Serge E. Hallyn
It looks like maybe just adding a struct
user_namespace* to a struct key should suffice.That's not quite sufficient. The per-UID
key_userstructs also need to be differentiated. Unfortunately, I can't just merge it intouser_structas I then end up with a reference loopuser_struct->uid_keyring->user_struct.
Quoted 6 lines
Rooting the
key_usertrees inuser_namespacewill probably do the trick.A couple of questions:
(1) A process may inherit a session keyring over
clone(). Should this be discarded ifCLONE_NEWUSERis set? Or would I need to copy it?
Someone else may have stronger feelings about this. Personally so long as a container setup program has a way of discarding the keyring manually I think that's fine.
Quoted 3 lines
(2) In a recent patch, I've given the root user its own quota limits. Is UID 0 always the root user in any container? Or would it make more sense just to scrap the per-root quota limits?
Yeah uid 0 may not have a bunch of privileges, but it is still the root user.
thanks,
-serge