[RFC PATCH 1/4] lsm: separate security_task_getsecid() into subjective and objective variants

[John Johansen]

On 3/9/21 4:28 PM, Paul Moore wrote:
> On Wed, Mar 3, 2021 at 7:44 PM Paul Moore <paul at paul-moore.com> wrote:
>> On Sun, Feb 21, 2021 at 7:51 AM John Johansen
>> <john.johansen at canonical.com> wrote:
>>> On 2/19/21 3:29 PM, Paul Moore wrote:
>>>> Of the three LSMs that implement the security_task_getsecid() LSM
>>>> hook, all three LSMs provide the task's objective security
>>>> credentials.  This turns out to be unfortunate as most of the hook's
>>>> callers seem to expect the task's subjective credentials, although
>>>> a small handful of callers do correctly expect the objective
>>>> credentials.
>>>>
>>>> This patch is the first step towards fixing the problem: it splits
>>>> the existing security_task_getsecid() hook into two variants, one
>>>> for the subjective creds, one for the objective creds.
>>>>
>>>>   void security_task_getsecid_subj(struct task_struct *p,
>>>>                                  u32 *secid);
>>>>   void security_task_getsecid_obj(struct task_struct *p,
>>>>                                 u32 *secid);
>>>>
>>>> While this patch does fix all of the callers to use the correct
>>>> variant, in order to keep this patch focused on the callers and to
>>>> ease review, the LSMs continue to use the same implementation for
>>>> both hooks.  The net effect is that this patch should not change
>>>> the behavior of the kernel in any way, it will be up to the latter
>>>> LSM specific patches in this series to change the hook
>>>> implementations and return the correct credentials.
>>>>
>>>> Signed-off-by: Paul Moore <paul at paul-moore.com>
>>>
>>> So far this looks good. I want to take another stab at it and give
>>> it some testing
>>
>> Checking in as I know you said you needed to fix/release the AppArmor
>> patch in this series ... is this patch still looking okay to you?  If
>> so, can I get an ACK at least on this patch?
> 
> Hi John,
> 
> Any objections if I merge the LSM, SELinux, and Smack patches into the
> selinux/next tree so that we can start getting some wider testing?  If
> I leave out my poor attempt at an AppArmor patch, the current in-tree
> AppArmor code should behave exactly as it does today with the
> apparmor_task_getsecid() function handling both the subjective and
> objective creds.  I can always merge the AppArmor patch later when you
> have it ready, or you can merge it via your AppArmor tree at a later
> date.
> 

I have some questions around selinux and binder but I don't have any
objections to you merging, we can always drop fixes on top if they
are necessary