Re: [LSM Stacking] SELinux policy inside container affects aprocesson Host

[Casey Schaufler <casey@schaufler-ca.com>]

On 7/23/2023 7:29 PM, Leesoo Ahn wrote:
> 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@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'.

SELinux and Smack rely on the fact that they manage security attributes
on all subjects and all objects. On a system where some objects are not
labeled because they are being managed by AppArmor instead, you are
going to have a security state that is muddled. How would you have a
host system that uses SELinux handle files in a container that is using
only AppArmor?

If the host processes never look at the files in the container you could
have a system that works the way you'd like. But how could you ensure that?


>
> 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?

I will put aside the question of whether having processes with
divergent security policies is reasonable for the moment. I know many
people believe that it isn't, and I think that there's real danger in
it.

I'm not a fan of making the call_ macros any fancier than they are.
I would rather see a local copy of the hook lists for processes that
use a different set than the base system.

>
> Best regards,
> Leesoo