Re: [RFC PATCH 2/4] selinux: clarify task subjective and objective credentials

On 2/19/21 3:29 PM, Paul Moore wrote: > SELinux has a function, task_sid(), which returns the task's > objective credentials, but unfortunately is used in a few places > where the subjective task credentials should be used. Most notably > in the new security_task_getsecid_subj() LSM hook. > > This patch fixes this and attempts to make things more obvious by > introducing a new function, task_sid_subj(), and renaming the > existing task_sid() function to task_sid_obj(). > > Signed-off-by: Paul Moore <paul(a)paul-moore.com&gt; I have a couple of questions below but the rest looks good > --- > security/selinux/hooks.c | 85 +++++++++++++++++++++++++++------------------- > 1 file changed, 49 insertions(+), 36 deletions(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index f311541c4972e..1c53000d28e37 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -229,10 +229,23 @@ static inline u32 cred_sid(const struct cred *cred) > return tsec->sid; > } > > +/* > + * get the subjective security ID of a task > + */ > +static inline u32 task_sid_subj(const struct task_struct *task) > +{ > + u32 sid; > + > + rcu_read_lock(); > + sid = cred_sid(rcu_dereference(task->cred)); > + rcu_read_unlock(); > + return sid; > +} > + > /* > * get the objective security ID of a task > */ > -static inline u32 task_sid(const struct task_struct *task) > +static inline u32 task_sid_obj(const struct task_struct *task) > { > u32 sid; > > @@ -2034,11 +2047,8 @@ static inline u32 open_file_to_av(struct file *file) > > static int selinux_binder_set_context_mgr(struct task_struct *mgr) > { > - u32 mysid = current_sid(); > - u32 mgrsid = task_sid(mgr); > - > return avc_has_perm(&selinux_state, > - mysid, mgrsid, SECCLASS_BINDER, > + current_sid(), task_sid_obj(mgr), SECCLASS_BINDER, > BINDER__SET_CONTEXT_MGR, NULL); > } > > @@ -2046,8 +2056,8 @@ static int selinux_binder_transaction(struct task_struct *from, > struct task_struct *to) > { > u32 mysid = current_sid(); > - u32 fromsid = task_sid(from); > - u32 tosid = task_sid(to); > + u32 fromsid = task_sid_subj(from); fromsid potentially gets used as both the subject and the object the following permission checks. It makes sense to use the same cred for both checks but what I am not sure about yet is whether its actually safe to use the subject sid when the task isn't current. ie. I am still trying to determine if there is a race here between the transaction request and the permission check.

> + u32 tosid = task_sid_subj(to); its not clear to me that using the subj for to is correct