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

David and Tim,
Thank you for your comments.
I still have some doubts, which I'd be happy for someone to dispell.
Becase if you can then VSTa is probably in the running to be the the
first secure
freely available OS.
[ Ive probably opened my mouth for Choices, Oberon, Amoeba and others to stick
assorted references down :-]

Tim Newsham wrote:
> Jonathon Tidswell wrote:
> > 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 decedents get only their fare share of the cpu.
This looks like an nice solution.

> The network and disk resources need to be protected by their servers
> not the kernel.
All resources need to be protected by their respective servers, a microkernel
design does not want to include excess material in the kernel, but
shifting the responsibility does not solve the problem it simply
increases the number of
places it needs to be addressed, and correspondingly the number of places
it can be poorly addressed.

> > 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).
It is possible to build systems that support other models on top of
existing models,
the degenerate case being to simulate the desired environment in full.
However to integrate these requires modifying kernel process structures and
file structures to handle the tagging needed for classifying data and
processes.
Equally tags need to be added for type-enforcement.
[ Adding them will likely change my view of the security of the system. ]

I would like to describe a Trojan horse that currently seems possible.
If I've slipped up please tell me so.

I write a useful utility 'po', which in addition to its role as an
excellent personal organiser utility with all the bells and whistles
starts a server (as you) which provides a
file system on some predefined port. This filesystem is an exact
replica of the
filesystem that 'po' can see, except that the permissions it exports
the data with
are non-existent --- i.e. someone using it accesses your files as you.

Obviously 'po' can only export access to files it gets, but this
requires that the access
of each and every program be restricted as far as possible.
This means that some automatic (users are lazy) and external to 'po'
(recall 'po'
isn't trustworthy) protection device limiting what 'po' may see, is required.
Obviously the above protection device must itself be protected from subversion.

> > 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.
Agreed on all points.

- JonT
Received on Tue Dec 13 23:41:44 1994