You raise a good point. My intuitive definition would go something like
this. In the initial LSM space we would have whatever is the primary
LSM and it would always be invoked about everything. However it
would view a single container (no matter what user in that container)
as having a single set of permissions. Then the LSM in the container
be asked to further validate accesses, but it would distinguish
between users in the container.
At this point it looks like if I am going to be effective at doing
anything I am going to need to step back watch SMACK get merged and
then really look at what the LSM modules are implementing. Then
I can refactor the whole mess and move additional functionality into
the LSM to help me achieve other things.
Yep. Although the isolation of a container with a completely
different set of namespaces is tight enough that except for people
debugging a container from processes in the container from outside the
container object exchange essentially doesn't happen.
You do raise a very good question here. Does an LSM implement a
different file permission system? Or does an LSM implement a firewall
between processes?
Certainly selinux seems too programmable to be considered just a
different file permission system.
Yes. There are many hard problems here and many people have tried and
failed in the past. That hasn't stopped me before, and I don't see
why security should be any different.
Eric
-
