[LSM Stacking] SELinux policy inside container affects aprocessonHost
Leesoo Ahn
lsahn at wewakecorp.com
Tue Jul 25 03:16:41 UTC 2023
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 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?
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
More information about the Linux-security-module-archive
mailing list