Re: [RFC PATCH ghak32 V2 01/13] audit: add container id

On 2018-04-23 19:15, Paul Moore wrote: > On Sat, Apr 21, 2018 at 10:34 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > > On 2018-04-18 19:47, Paul Moore wrote: > >> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs <rgb(a)redhat.com&gt; wrote: > >> > Implement the proc fs write to set the audit container ID of a process, > >> > emitting an AUDIT_CONTAINER record to document the event. > >> > > >> > This is a write from the container orchestrator task to a proc entry of > >> > the form /proc/PID/containerid where PID is the process ID of the newly > >> > created task that is to become the first task in a container, or an > >> > additional task added to a container. > >> > > >> > The write expects up to a u64 value (unset: 18446744073709551615). > >> > > >> > This will produce a record such as this: > >> > type=CONTAINER msg=audit(1519903238.968:261): op=set pid=596 uid=0 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0 ses=1 opid=596 old-contid=18446744073709551615 contid=123455 res=0 > >> > > >> > The "op" field indicates an initial set. The "pid" to "ses" fields are > >> > the orchestrator while the "opid" field is the object's PID, the process > >> > being "contained". Old and new container ID values are given in the > >> > "contid" fields, while res indicates its success. > >> > > >> > It is not permitted to self-set, unset or re-set the container ID. A > >> > child inherits its parent's container ID, but then can be set only once > >> > after. > >> > > >> > See: https://github.com/linux-audit/audit-kernel/issues/32 > >> > > >> > Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com&gt; > >> > --- > >> > fs/proc/base.c | 37 ++++++++++++++++++++ > >> > include/linux/audit.h | 16 +++++++++ > >> > include/linux/init_task.h | 4 ++- > >> > include/linux/sched.h | 1 + > >> > include/uapi/linux/audit.h | 2 ++ > >> > kernel/auditsc.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++ > >> > 6 files changed, 143 insertions(+), 1 deletion(-)

> >> > /* audit_rule_data supports filter rules with both integer and string > >> > * fields. It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and > >> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > >> > index 4e0a4ac..29c8482 100644 > >> > --- a/kernel/auditsc.c > >> > +++ b/kernel/auditsc.c > >> > @@ -2073,6 +2073,90 @@ int audit_set_loginuid(kuid_t loginuid) > >> > return rc; > >> > } > >> > > >> > +static int audit_set_containerid_perm(struct task_struct *task, u64 containerid) > >> > +{ > >> > + struct task_struct *parent; > >> > + u64 pcontainerid, ccontainerid; > >> > + > >> > + /* Don't allow to set our own containerid */ > >> > + if (current == task) > >> > + return -EPERM; > >> > >> Why not? Is there some obvious security concern that I missing? > > > > We then lose the distinction in the AUDIT_CONTAINER record between the > > initiating PID and the target PID. This was outlined in the proposal. > > I just went back and reread the v3 proposal and I still don't see a > good explanation of this. Why is this bad? What's the security > concern? I don't remember, specifically. Maybe this has been addressed by the check for children/threads or identical parent container ID. So, I'm reluctantly willing to remove that check for now.

> > Having said that, I'm still not sure we have protected sufficiently from > > a child turning around and setting it's parent's as yet unset or > > inherited audit container ID. > > Yes, I believe we only want to let a task set the audit container for > it's children (or itself/threads if we decide to allow that, see > above). There *has* to be a function to check to see if a task if a > child of a given task ... right? ... although this is likely to be a > pointer traversal and locking nightmare ... hmmm. Isn't that just (struct task_struct)parent == (struct task_struct)child->parent (or ->real_parent)? And now that I say that, it is covered by the following patch's child check, so as long as we keep that, we should be fine.

> >> I ask because I suppose it might be possible for some container > >> runtime to do a fork, setup some of the environment and them exec the > >> container (before you answer the obvious "namespaces!" please remember > >> we're not trying to define containers). > > > > I don't think namespaces have any bearing on this concern since none are > > required. > > > >> > + /* Don't allow the containerid to be unset */ > >> > + if (!cid_valid(containerid)) > >> > + return -EINVAL; > >> > + /* if we don't have caps, reject */ > >> > + if (!capable(CAP_AUDIT_CONTROL)) > >> > + return -EPERM; > >> > + /* if containerid is unset, allow */ > >> > + if (!audit_containerid_set(task)) > >> > + return 0; > >> > + /* it is already set, and not inherited from the parent, reject */ > >> > + ccontainerid = audit_get_containerid(task); > >> > + rcu_read_lock(); > >> > + parent = rcu_dereference(task->real_parent); > >> > + rcu_read_unlock(); > >> > + task_lock(parent); > >> > + pcontainerid = audit_get_containerid(parent); > >> > + task_unlock(parent); > >> > + if (ccontainerid != pcontainerid) > >> > + return -EPERM; > >> > + return 0;

> >> > +static void audit_log_set_containerid(struct task_struct *task, u64 oldcontainerid, > >> > + u64 containerid, int rc) > >> > +{ > >> > + struct audit_buffer *ab; > >> > + uid_t uid; > >> > + struct tty_struct *tty; > >> > + > >> > + if (!audit_enabled) > >> > + return; > >> > + > >> > + ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_CONTAINER); > >> > + if (!ab) > >> > + return; > >> > + > >> > + uid = from_kuid(&init_user_ns, task_uid(current)); > >> > + tty = audit_get_tty(current); > >> > + > >> > + audit_log_format(ab, "op=set pid=%d uid=%u", task_tgid_nr(current), uid); > >> > + audit_log_task_context(ab); > >> > + audit_log_format(ab, " auid=%u tty=%s ses=%u opid=%d old-contid=%llu contid=%llu res=%d", > >> > + from_kuid(&init_user_ns, audit_get_loginuid(current)), > >> > + tty ? tty_name(tty) : "(none)", audit_get_sessionid(current), > >> > + task_tgid_nr(task), oldcontainerid, containerid, !rc); > >> > + > >> > + audit_put_tty(tty); > >> > + audit_log_end(ab); > >> > +} > >> > + > >> > +/** > >> > + * audit_set_containerid - set current task's audit_context containerid > >> > + * @containerid: containerid value > >> > + * > >> > + * Returns 0 on success, -EPERM on permission failure. > >> > + * > >> > + * Called (set) from fs/proc/base.c::proc_containerid_write(). > >> > + */ > >> > +int audit_set_containerid(struct task_struct *task, u64 containerid) > >> > +{ > >> > + u64 oldcontainerid; > >> > + int rc; > >> > + > >> > + oldcontainerid = audit_get_containerid(task); > >> > + > >> > + rc = audit_set_containerid_perm(task, containerid); > >> > + if (!rc) { > >> > + task_lock(task); > >> > + task->containerid = containerid; > >> > + task_unlock(task); > >> > + } > >> > + > >> > + audit_log_set_containerid(task, oldcontainerid, containerid, rc); > >> > + return rc; > >> > >> Why are audit_set_containerid_perm() and audit_log_containerid() > >> separate functions? > > > > (I assume you mean audit_log_set_containerid()?) > > Yep. My fingers got tired typing in that function name and decided a > shortcut was necessary. > > > It seemed clearer that all the permission checking was in one function > > and its return code could be used to report the outcome when logging the > > (attempted) action. This is the same structure as audit_set_loginuid() > > and it made sense. > > When possible I really like it when the permission checks are in the > same function as the code which does the work; it's less likely to get > abused that way (you have to willfully bypass the access checks). The > exceptions might be if you wanted to reuse the access control code, or > insert a modular access mechanism (e.g. LSMs). I don't follow how it could be abused. The return code from the perm check gates setting the value and is used in the success field in the log.