capabilities / security (was Re: VSTa - First Impressions)

Tim Newsham newsham@zang.kcc.hawaii.edu
Mon, 12 Dec 1994 20:48:36 -1000 (HST)


> Some details on problems of risk management (security):
> 
> The problem of availability is sometimes divided into protection against
> denial-of-service (DOS :-) attacks and reliability issues.
> I'll leave reliability aside until VSTa goes commercial :-), but DOS 
> attacks are
> normally aimed at limited resources - network, memory, disk, CPU, etc.

the schedulers tree nature can be used to protect cpu resources.  Each
process and its decendants get only their fare share of the cpu.
The network and disk resources need to be protected by their servers
not the kernel.

> Non-disclosure is normally an issue of simple Trojan horses, covert 
> channels (unintended information channels) and users incorrectly 
> setting their permissions.

I think systems that block the flow of information from "classified"
to "unclassified" can be built on top of the current protection model.
I also think that schemes such as "type enforcement" might be
implementable on top of the current mode.  This takes care of issues 
such as trojan horses (trojan horse can be run at higher security level
but can never communicate information to a lower security level without
going through a covert channel).

> As justification for my pedantry, I'd like to refer people the effort 
> currently being
> expended to develop and deploy firewalls and companies and universities all
> around the world --- standard systems are not secure enough.

efforts to build firewalls on unix based systems?  The security model
provided with unix is not very flexible.  This is a well known fact.
(Security was an afterthought in unix, not part of the design spec).
Recently a company introduced a firewall based on BSDI with additions
to do type-enforcement which is a step in the right direction.

> regards,
> JonT

In my opinion the primitives provided by VSTa are sufficient to
build a high-security system.

                                    Tim N.