On Mon, Mar 18, 2013 at 03:16:52PM -0700, Eric W. Biederman wrote: > Adding the containers list so folks with container expertise can see > what is being proposed. > > Aristeu Rozanski <arozansk(a)redhat.com&gt; writes: > > > This patchset introduces a new audit record to follow all USER records which > > provides namespace information of the process. The idea is to allow processes > > in containers to create records in the host system while providing means to be > > filtered out. > > It looks like this mechanism makes it easy for an unprivileged program > to spam and overwhelm the audit log. > > > For each new namespace, a unique procfs inode number is allocated and this > > number has been used by userspace to determine which processes belong to the > > same namespace. These numbers are used in the new audit record. > > > > Applications such as libvirt-sandbox and lxc can then report the same numbers > > when a container is created and destroyed allowing to map records to a certain > > container. Maybe the next step would be having a record for whenever a new > > namespace is created? > > > > First 6 patches are needed in order to get each namespace's inode number. > > Grumble the existing methods can be used you don't have to introduce a > whole new set of methods. Grumble. Besides the bug of assuming that > the inodes now and forever will be the same across all instances of > proc. the existing methods are for procfs use and I didn't want to abuse it. like I said the other email, the fact that it's not a reliable way to indefinitely describe a namespace due to multiple procfs instances or migration, the whole idea is flawed.

> > Patch 7 properly defines the new record that is related to the USER > > record > > Not agmenting the current user records seems a little odd to me. > > You also continue in this my current policy of not allowing any audit > records in the container itself, so I a don't quite know what the point > of all of this is. your current policy wasn't known to me and /* Only support the initial namespaces for now. */ sounds like something that didn't happen for other reasons

> > Patch 8 allows USER records to be generated from different namespaces > > Which essentially allows any user to create any USER record they want > whenever they want. > > > Here's an example of output: > > type=CRED_DISP msg=audit(1363528861.403:311): pid=20016 uid=0 auid=0 ses=45 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success' > > Ok. This seems totally bizarre. You are running a container with a > user namespace with some uid mapped to uid 0? on the notes section: - while the last patch allows a new userns to send audit records, I haven't look yet on making sure it has proper capabilities so regular users' containers can create records so I haven't tried it with userns. It's a RFC.

That's a regular record to show the related records, using initial namespaces. like I stated in the email, I wasn't sure how I'd handle capabilities but the idea would be to allow containers to log to the system's auditd. since inode numbers aren't more reliable for more than a moment, I guess there's no other way than having an audit namespace and run an audit daemon inside the container (and communicate over the network like an individual host).

It is always possible to pick the instance of /proc connected to the initial pid namespace. And there is a device number you can use to say that.

The reasons were simply that to my knowledge no one has thought through how audit records and namespaces make sense to interact. My expectation would be that an extention of audit records would be logged on a per container basis. But I don't have any motivating examples.

I though you would have taken the time to run it at least once, or to perhaps have manually edited your example to see how things would fit together.

What was really missing from your RFC is a motivating example. I sort of see that in your paragraph above but it isn't clear to me. What is lost by not allowing USER audit records from processes in containers? What is gained by implementing user process to have them? And of course what are your thoughts on preventing unprivileged users overwhelming the audit subsystem.

Quoting Aristeu Rozanski (arozansk(a)redhat.com): > 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.

Quoting Eric Paris (eparis(a)redhat.com): > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote: > > Quoting Aristeu Rozanski (arozansk(a)redhat.com): > > > 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.

On Wed, 2013-03-20 at 13:49 -0500, Serge Hallyn wrote: > Quoting Eric Paris (eparis(a)redhat.com): > > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote: > > > Quoting Aristeu Rozanski (arozansk(a)redhat.com): > > > > 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. 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?) 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?

Going to have to have audit namespaces to. But only CAP_AUDIT_READ would make sense in the new audit namespace...

/me wishes containers were a 'thing' instead of a bucket of semi-related nuts and bolts.

Eric Paris <eparis(a)redhat.com&gt; writes: > On Wed, 2013-03-20 at 13:49 -0500, Serge Hallyn wrote: >> Quoting Eric Paris (eparis(a)redhat.com): >> > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote: >> > > Quoting Aristeu Rozanski (arozansk(a)redhat.com): >> > > > 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.

Quoting Eric Paris (eparis(a)redhat.com): > So the kernel socket(s) would be per network namespace, but we divide > messages per user namespace? Which socket do I send them on, > considering the possible crazy many<->many mappings between user and > network namespaces. It all makes me cry a little. not many-many - each netns is owned by exactly one userns. The userns from which the netns was created.