[LSM Stacking] SELinux policy inside container affects aprocesson Host
Casey Schaufler
casey at schaufler-ca.com
Mon Jul 24 21:35:21 UTC 2023
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 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'.
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
More information about the Linux-security-module-archive
mailing list