Colin Walters <walters@xxxxxxxxxx> wrote: > Providing a feature without *known* users in a security-sensitive context > seems to me to be something to think twice about. Ummm... Kernel DNS lookups, NFS idmapper upcalls. CIFS could use it too. > Kind of - what I'm getting at is that today, changing any of the kernel > upcalls is a fully privileged operation. Yes. Upcalls are more secure but finding out the collection of namespaces in which to run an upcall is a real pain - and Eric's 'concrete' method doesn't actually work. > (Wait, is /sbin/request-key really hardcoded in the kernel? I guess that's > good from the perspective of not having containers be able to change it > like they could /proc/sys/kernel/core_pattern if it was writable, but > it seems surprising) Namespaces didn't exist at the time. > Anyways, if we now expose a method to configure this, we have to look > at the increase in attack surface. To quote: > In practice again, most container implementations I'm aware of use > seccomp today to simply block off access to the keyring. We're going to have to deal with that, but it's going to take some support on the kernel side. I think it may require a 'key' namespace - but that's going to have potentially difficult interactions with the 'net' namespace for network filesystems where your process's key and net namespaces are different to the that of the superblock you're trying to access. > > > Basically my instinct here is to be conservative and have > > > KEYCTL_SERVICE_ADD require CAP_SYS_ADMIN and only affect the userns > > > keyring. Sorry, what 'userns' keyring? > At a high level I'm glad you're looking at the "service fd" model instead of > upcalls - I do think it'll get us to a better place. I disagree, but it may be the only way, given the unholy mess in which the Linux 'container' system works. David -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
