Re: [LSM Stacking] SELinux policy inside container affects aprocessonHost

[Leesoo Ahn <lsahn@wewakecorp.com>]

2023-07-25 오전 6:35에 Casey Schaufler 이(가) 쓴 글:
> 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?

I think we could deal with that using origin call_ macro only if the 
following cases that alloc a task, socket, make a file and so forth 
which do newing objects and subjects that must have both security 
context for preventing a security state that would be muddled. On the 
other hands, in a case of operations that like read, load, mmap are to 
call the customized call_ macro with ilsm to conditionally branch.

[...]

> I would rather see a local copy of the hook lists for processes that
> use a different set than the base system.

Could you explain the latter one, please?

best regards,
Leesoo