[LSM Stacking] SELinux policy inside container affects aprocesson Host

[Leesoo Ahn]

2023-07-18 오전 12:51에 Casey Schaufler 이(가) 쓴 글:
> On 7/17/2023 8:24 AM, Leesoo Ahn wrote:
>  > 23. 7. 7. 23:20에 Paul Moore 이(가) 쓴 글:
>  >> On Fri, Jul 7, 2023 at 4:29 AM Leesoo Ahn <lsahn at wewakecorp.com> wrote:
>  >>  > 2023-07-06 오후 10:43에 Paul Moore 이(가) 쓴 글:
[...]>  >> If you are interested in stacking SELinux and AppArmor, I 
believe the
>  >> only practical solution is to run SELinux on the host system (initial
>  >> namespace) and run AppArmor in the containers. Even in a world where
>  >> SELinux is fully namespaced, it would likely still be necessary to run
>  >> some type of SELinux policy on the host (initial namespace) in order
>  >> to support SELinux policies in the containers.
>  >
>  > Thank you for the reply. It really helped me to know the current
>  > status of them and what to do now.
>  >
>  > Just a little information for who is interested in the stacking that
>  > we decided to branch the LSM hooks by which lsm the current process is
>  > in instead of entirely calling them in order.
> 
> Could you describe your approach more fully?

As far as I know, the current stacking feature is implemented calling 
the entire hooks in order of 'lsm=' boot parameter. But our desire must 
be calling a proper hook at a time by a task's current LSM, for instance 
Apparmor 'or' SELinux instead of 'and'.

And so we have been considering adding two new hooks which work as the 
same as the origin hooks but additionally branch to a proper hook 
function with the information of current LSM by calling lsm_task_ilsm().

The following changes are a part of our approach,

------ code part ------
#define call_int_hook_by_ilsm(FUNC, ILSM, IRC, ...) ({                 \
        int RC = IRC;                                           \
        do {                                                    \
                struct security_hook_list *P;                   \
                int id; \
                                                                \
                id = (ILSM == LSMBLOB_INVALID) \
                        ? lsm_slotlist[0]->id \
                        : lsm_slotlist[ILSM]->id; \
                hlist_for_each_entry(P, &security_hook_heads.FUNC, list) { \
                        if (P->lsmid->slot != LSMBLOB_NOT_NEEDED && id 
!= P->lsmid->id) \
                                continue; \
                        RC = P->hook.FUNC(__VA_ARGS__);         \
                        if (RC != 0)                            \
                                break;                          \
                }                                               \
        } while (0);                                            \
        RC;                                                     \
})

[...]

int ilsm = lsm_task_ilsm(current);
ret = call_int_hook_by_ilsm(mmap_addr, ilsm, 0, addr);
------------

We are still worrying about the part of calling lsm_task_ilsm() with 
'current', it seems dangerous in some unknown cases.

What do you think about this approach, Casey?

Best regards,
Leesoo