[cap-talk] process 'tainting': *-property or not *-property

[Rob J Meijer]

>>I may be wrong, but I thought that asynchrounous IPC (queues)
>>combined with the *-property when all that is communicated is data
>>was all that was needed for that. Could you please elaborate?
>
> No.  If that's all you do, there are still covert channels out the wazoo.
> Every shared resource is a potential covert channel.  For example, there
> are covert channels due to the sharing of cache (e.g., L1, L2, you name
> it).  There was a recent bit of publicity about a side channel caused by
> hyper-threading (which can, of course, be used as a covert channel, too):
>   http://www.daemonology.net/hyperthreading-considered-harmful/
> Wall-banging (modulation of system load or usage of any shared resource)
> can be used for covert channels.  If any of your applications are
> permitted to use the network, there are many ways they can covertly leak
> data to someone else on the network.  These are just a few examples.

I see what you mean, but arn't these all just basic resource management
issues?
As long as you have proper resource allocation possibilities for your
zones these should not be relevant, right? If the OS does not have
resource management it becomes just a bit more aquard as you need to
distribute your zones over seperate machines, or am I missing soemthing?
Resource management related covert-channel issues are imho simply either
OS or distributed computing issues, and not realy an issue in confinement
modeling as such, at least when looking at data only MLS with static IPC
channels between processes. With resource management making its way even
into the non trusted (relatively) mainstream OS world, saying that these
kinds of convert channels are insolvable seems like a strange position to
still take.

As for processes with direct network access either are subject to
proof-level code audit, or are fitted with a low clearance level, so that
one is a non-issue I think. Basically network access 'is' IPC, and thus
should be subject to IPC paterns.

Further it remains important that we realize that the acceptable size (one
time data) and/or speed (true channel) of covert channels for any two
levels
of clearance is either explicitly defined in a MLS security policy document,
and increases as the clearance level of the highest clearance process
decreases, or (my preference) is defined as a result of a thourough risk
analysis. The mere fact that the risk posed by a covert channel is found
to be substantialy lower than that of a single zone design makes the use
of MLS justified even in enviroments that do not implement resource
management.
This is also one of the reasons why I try to define the purely IPC based
confinement, given that filehandle/process or JVM based capability design
can both implement the same patern on a different level.

> Surely this stuff is well-known in the MLS community?  I feel like
> I'm explaining the Catholic religion to the pope.  I teach this stuff
> in our undergraduate security class -- it's pretty standard material.
> Much of this is in Lampson's original paper:
>   http://research.microsoft.com/lampson/11-Confinement/Abstract.html
> Have I misunderstood the question?
>
>>Agreed, but the concept of 'dropping state' may reset the lable to the
>>lower bound. Without this the system would soon become the black hole
>>that Ping described, for this I found it nessisary to stress this point.
>
> Naah.  I don't think that's necessary.  The standard solution is to
> just run a new copy of the program.  You don't need to have any fancy
> system support for 'drop state and reset the label'.  Instead, you just
> let the original process die and start up a new copy of the program.

I think this is essentialy a specific instance of the same solution.

> The dynamic label on the new process will be unrelated to the label on
> the old process, so you've achieved the effect of a 'reset' without
> any special system support.  If you want to communicate some partial
> information from the old process to the new process, then you use
> any mechanism you like for storing state (e.g., a filesystem) or for
> inter-process communication to communicate that information from the old
> process to the new process, and the rules for tracking information flow
> automatically will cause the new process to get the right label.

Yes, this is exactly the same patern implementend on the process level.

> Anyway, in the standard MLS systems I've read about, I thought you're
> not supposed to be able to ever drop your label (exception: there are
> certain trusted processes that are exempt from all the rules).  Is what
> you are describing some non-standard variant?  Or am I just misinformed
> about how the MLS systems in the literature work?

What I think is that you are implicitly applying confinement modeling to the
process/OS level only, but just as capability modeling can be done on
the OS/process level on the one side, and on the object level on the other
side, so can confinement modeling. If you replace trusted process you
mentioned by a trusted (proof level code audit) object within a trusted
library, you can apply the exact same patern (on the lower of the
clearance levels) by calling the destructor of the active object
constructing it again and handing it back a pointer to its IPC (and/or
storage) possibilities.

The OS/process based implementation is inherantly much more secure, just
as OS based capability implementations are inherently much more secure
than for example a JVM based solution, this does not make the JVM based
solution unusable for everything though, and the same goes for confinement
modeling.

Rob