The secmark "one user" policy

[John Johansen]

On 06/22/2017 08:02 PM, James Morris wrote:
> On Thu, 22 Jun 2017, John Johansen wrote:
> 
>>> Trying to stack major LSMs arbitrarily and exposing that to userland is an 
>>> architectural mess, which is what these kinds of problems are really 
>>> telling us.
>>>
>>
>> The use case I keep seeing is not exposing multiple LSMs to the user
>> space. Its the container where the container wants a different LSM
>> than the system is running.
>>
>> Stacking 2 LSMs in that case and only exposing one to user space isn't
>> so unreasonable.
> 
> In this case, would they both be labeling LSMs which need to label 
> packets?
> 
> I can imagine having Smack or SELinux as the base LSM and then having 
> AppArmor in the container, but having Smack and SELinux in that 
> combination would still not make sense to me.
> 

I don't see why not. The container could be built expecting smack
labeling, selinux applies 1 or just a few labels to the whole
container, and accesses within the container are mediated fine grained
with smack.

If you are talking system containers like LXC/D this makes even more
sense, your running selinux on the host and the container is using smack
or AppArmor.

It does mean you would have to do some namespacing of some sort so that
the interface would know which LSM to multiplex to. Tasks in the container
write to smack or apparmor, system tasks get selinux.

selinux still gets to enforce a system policy even on the container as
it does today, and the other LSM applies policy as if the container is
the system (at least for system containers).

>>
>>> How can a user be expected to reason about a system which is running 
>>> multiple independent MAC security models simultaneously?  It's a terrible 
>>> idea.
>>>
>>
>> At a generic system MAC level I agree, but not all LSMs that need
>> state are MACs and in the more limited container case it isn't so
>> unreasonable.
> 
> Can you provide a concrete example of needing two independent packet 
> labeling LSMs?
> 

System containers come to mind, as mentioned above. Take an Ubuntu LXC
container and run it on fedora or RHEL. While apparmor isn't doing
packet label yet, patches for that should float up to the list soon,
and really it doesn't have to be ubuntu/apparmor the container guys
want to be a replacement for virtualization, allowing you to run
applications from different OSes on the same host.

You could take the same basic situation of an LXC container built
expecting smack and run it on fedora/RHEL with selinux enforcing for
the host. Except it isn't currently supported.

Right now LXC is limited as to what it can do with the MAC system in
the container. It can currently stack an apparmor host with an
apparmor guest each applying their own policy, but I know they would
love to be mix and match MAC systems, getting them closer to being a
replacement for virtualization. Again it could be argued that going
full virtualization is a better solution if you want different MAC
systems but people will choose (currently are choosing) to run the
container without a MAC instead of going with virtualization.

Another use case would be running snappy packages (chosen because it
is using apparmor to enforce some things, but same could be done with
flatpak if/when it starts using an LSM) on fedora. Currently you have
to either boot the system into apparmor (disabling selinux) or disable
part of the applications mediation. Again yes apparmor doesn't label
packets today but it will soon.

A little more speculatively another potential example would be an LSM
doing a personal firewalls around individual applications. Its really
very similar to the snappy/flatpak sandboxing of apps but maybe
someone wants that with out the additional baggage of a bigger LSM.
Whether it would ever get in upstream is a separate question.

I think we are just starting to scratch the surface of how stacking
will be used. Especially with all the different container/sandboxing
that is going on, and projects like flatpak and snappy pushing to be
system agnostic.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html