** On Mar 27, Linda Walsh scribbled:
> Grendel wrote:
> > The clearance levels can be equivalent to the process privilege levels - in
> > respect to memory usage - so that the processes of the most privileged users
> > can be ruled out of the 'kill on OOM' pool - simply marked "non killable".
> ---
> Problem comes when you have two sensitivity labels that are not
> able to be hierarchically compared. They may be at equal sensitivity levels
> but may be in disparate categories that have no ordering -- like say, you have
> the "Harvard University" category and the "Yale University" category that have
> no intrinsic comparable value (other than of the attendees or proponents of
> such :-)). They both have the same sensitivity level (say "Faculty" vs. say
> "Undergrad"). But kernel can't determine a hierarchy for the categories.
Yup, that's definitely a problem. And one that probably requires human
intervention, or a temporary and arbitrary shuffling of priorities within
the same group when the system detects such situation. Somebody earlier
mentioned that in such situation IRIX goes to a deadlock - is it a sensible
behavior?
> > In a word the processes are guaranteed not to be killed in such situation.
> > If the compartmented mode is to be completely secure, the machine should use
> > separate _hardware_ for every clearance level, or guaranteed separation of
> > VMs, am I correct?
> ---
> Separate hardware may be the ideal. It might be that researchers
> at Harvard and Yale might both wish to have a 256P machine, but the reality
> is that both schools might not be able to afford such a machine and but
> might be able to 'copurchase' such a machine but still want secure
> separation for their research. Covert channels as referred to by Alan C. and
> Jesse P. may have acceptably low bit rates (say <10 bits/second) if what
> they are working on are Gigabit datasets. Obviously, we'd like to know what
> covert channels are possible and what the maximum bit rate of each is, so
> Harvard and Yale can decide if those are acceptable. Their requirements
> might be different than say if Caltech U. and Stanford U. were to share a
> machine.
Now that I think about it, the compartmented mode on our average PC is quite
improbable :)), but with a cluster of PCs it can be quite possible to do and
very flexible. But what if the Linux kernel supported full virtualization of
all of its sharable resources? That is, it would create full VMs with
virtual network cards, CPUs, pure virtual memory, block devices?
> > Combining the clearance levels, appropriate capabilities (as you proposed
> > before) and memory access priorities could guarantee that mr. President
> > won't run out of memory :)
> ---
> Ok, zap forward to future. US and Euro countries decide to band
> together to buy a 256GP machine -- to predict the weather, among other things.
> Now we have incomparable entities (unless you want to start a squabble). Mr.
> Pres is at the same priority level as other country leaders, but is
> 'incomparable' to them. We can't prioritize memory within that group. If
Not automatically, no.
> there ia memory shortage, Mr. Prez can lobby congress and the other Euro
> nations for more memory on the 256Giga-processor machine. But he won't
> be running along and have his vi session killed out from under him (though
> the concept is a bit amusing...:-)).
Heh :)))), yeah - that's a bit of a comedy :)). But, what if the Mr. Prez's
process isn't killed but simply put on hold and Mr. Prez sees a nice cute
box popping up on his screen saying "We're sorry - a temporary shortage of
memory caused your process to stop. Please wait patiently." The process is
put on the wait queue until the memory becomes available. To prevent
starvation, the system should be preemptive, of course. The processes in
separate priority groups would be serviced in parallel mode until memory
comes short, then the higher priorities win of course. The processes in the
same priority group would have to be serialized for the access to memory if
the need arises. How about that scenario? No killing, some patience
sometimes :))
marek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:21 EST