Eric Paris <eparis@xxxxxxxxxx> writes: > On Wed, 2013-03-20 at 13:49 -0500, Serge Hallyn wrote: >> Quoting Eric Paris (eparis@xxxxxxxxxx): >> > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote: >> > > Quoting Aristeu Rozanski (arozansk@xxxxxxxxxx): >> > > > This is a bit fuzzy to me, perhaps due I'm not fully understanding >> > > > userns implementation yet, so bear with me: >> > > > I thought of changing so userns would not grant CAP_AUDIT_WRITE and >> > > > CAP_AUDIT_CONTROL unless the process already has it (i.e. it'd require >> > > >> > > Seems like CAP_AUDIT_WRITE should be targeted against the >> > > skb->netns->userns. Then CAP_AUDIT_WRITE can be treated like any other >> > > capability. Last I knew (long time ago) you had to be in init_user_ns >> > > to talk audit, but that's ok - this would just do the right thing in >> > > any case. >> > >> > kauditd should be considered as existing in the init user namespace. So >> > I'd think we'd want to check if the process had CAP_AUDIT_WRITE in the >> > init user namespace and if so, allow it to send messages. Who care what >> > *ns the process exists in. If it has it in the init namespace, go >> > ahead. Thus the process that created the container would need >> > CAP_AUDIT_WRITE in the init namespace for this to all work, right? >> >> Yes. What I was suggesting is intended to work if that situation ever >> changes. But I have zero complaints about doing it as you say, as I >> doubt it ever will/ought to change. >> >> That basically means CAP_AUDIT_WRITE would be worthless in a non-init >> userns. That's fine - at least the rules would be consistent. > > [veering away from this particular patch] > > We are also talking about adding a CAP_AUDIT_READ and sending messages > via multicast on the audit socket. The problem is I don't know how the > audit socket could work in the network namespace world. Hmm. I don't quite know how CAP_AUDIT_READ could work. When delivering a message to a socket you really don't know who is on the other end. > Right now kauditd has: > > audit_sock = netlink_kernel_create(&init_net, NETLINK_AUDIT, &cfg); > > So there won't ever be anything on the kernel side of the audit socket > in a non-init network namespace. Lets say that is fixed somehow (I > assume it's possible? something? magic pixies?) One socket for each network namespace... It is a pain but doable. > I think we'd somehow > need to do the CAP_AUDIT_READ check against the user namespace > associated with the network namespace in question? But what messages > should go to this userspace auditd? Messages generated by processes in that user namespace? > Going to have to have audit namespaces to. But only CAP_AUDIT_READ > would make sense in the new audit namespace... Given the connection of audit and security I think if we add support for a non-global auditd the user namespace seems to fit. The user namespace is certainly where all of the security connected bits go. Architecturally it gets a little tricky as it seems to make sense to generate audit messages that make sense to the process receiving them, which would mean actually generating a different audit message for different receiving contexts. I find the auditsc code odd. We log file descriptor numbers when a file is mmaped? What is something so process relative good to anyone? On a slightly different tangent. Do we want to update the AUDIT_CAPSET message to report the user namespace whose caps we are changing or perhaps to surpress the message outside of the initial user namespace. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
