[cap-talk] Re: OS frustration - POLA for Croquet?
John Carlson
john.carlson3 at sbcglobal.net
Wed May 11 23:19:23 EDT 2005
There is a pun at the end of this email. If you don't want to read the
email, but
are interested in the POLA pun, scroll down.
Jed at Webstart wrote:
> At 01:13 AM 5/7/2005, John Carlson wrote:
>
>>> When I consider that the framework for all of today's relevant
>>> operating
>>> systems (Windows and Unix) was essentially frozen in place in about
>>> 1970 ... and that their base underlying access control model (ambient
>>> authority) is so broken as to keep all of today's systems fundamentally
>>> unsecurable... Well, I find that quite discouraging. ... I don't
>>> expect to
>>> see that (OS level POLA) happen within my lifetime (still a while
>>> yet in
>>> computer terms, hopefully ~20 years). Sad and frustrating.
>>
>
>> Jed, this is why I have focused some of my energies at the
>> "translation problem."
>> If somehow, we could translate from one API library to another API
>> library, we
>> would solve a lot of our problems.
>
>
> Perhaps. But can you tell me this - If the source API library doesn't
> support
> POLA authority management, how can any effective POLA management of
> authorities show up in applications running on the translated API
> library -
> even if there might be some authority management interfaces in the
> destination API library (which I'm not aware of, but we can dream)?
> If I could understand how that base problem can be resolved then
> perhaps I could develop some more confidence in this approach.
>
Are you saying authority management interfaces don't exist? That's
really very humorous. Maybe there is a fundamental problem...we don't
know what the destination API library is yet.
>> I think some of the new stuff that converts
>> C/C++ to Java offers promise, if it manages to gain traction in the
>> open source
>> community. However, of the two efforts I am aware of, one costs
>> $.25 per line,
>> and the other is dependent on closed source licenses from IBM.
>> Neither supports changing
>> the GUI library. If we can move the programmers to a language like E
>> with IDE support
>> then we can change the underlying OS, I think (I have no clue how
>> dependent E is on
>> the OS, or whether it already has an IDE). So perhaps we should
>> focus on the
>> translation problem, converting C and C++ code to a language like E,
>> and providing
>> appropriate programmer tools for E.
>
>
> If somehow translating could "inject" authority management into
> applications then
> it might help more toward POLA, but I don't see how it can.
>
Well, first I would have to see such a authority management API to see
if it was possible or
not. Looking at E, it seems reasonable that you could port
applications, by creating facets.
Perhaps E is not a true capability system. It might have to be
human-directed translation,
but perhaps once the direction is done, massive amounts of code could be
translated. I
don't have a whole lot of experience with E yet, maybe someone can share
where the
authority management is located in E. If authority management is
mostly hidden from
the E programmer, it seems like it could be hidden from the application
as well. Perhaps
just porting the code to E, will allow authority management to be added
easily later. I
would need an example of something required in E that we couldn't
provide with some
translation program.
Also I have a question of whether capabilities are a "cross-cutting"
concern and may
be added after the fact through aspect oriented programming. I don't
understand how
this might be done, but I don't know capabilities very well, and I just
started on aspect
oriented programming. I could see replacing all URLs with
YURLs....that's the kind
of cross cutting I am talking about. If you don't know aspect oriented
programming, it's
designed to inject code before and after method calls and instead of
method calls,
usually in Java. It can be done at various stages, usually after or
during compilation.
>> It is true in a capitalistic society that the market determines the
>> preferred solution.
>> Here, the market has determined the preferred solution by the
>> applications &
>> ease of use, not by the security of the OS. If a secure OS has
>> compatible applications
>> [ minus the security holes ] & ease of use, then there will be no
>> reason for sticking
>> with the unsecure OS. I will sign up for making compatible
>> applications for a secure OS.
>> Where do I sign up? Do we need a capability secure windowing
>> system? GUI
>> library? I have interest in those as well. I may need additional
>> training in building
>> POLA applications.
>>
>> I don't know a whole lot about EROS yet. Should I port Open
>> Croquet/Squeak to EROS? For
>> those who don't know Open Croquet, it's a networked 3D Graphics OS
>> built on Squeak and
>> OpenGL. They want to use capabilities for their security. I guess I
>> would work on providing
>> OpenGL (or something similar) driver support for EROS before Open
>> Croquet.
>
>
> I appreciate your enthusiasm and willingness to "dig in" John.
>
Ah, I have enthusiasm, but I have trouble digging in. That's why I
think I need some project
where a GUI is very visible. I like the payback of seeing something
working visually. That's
why I got into computer science in the first place. I am of the Apple
II generation. I suffered
through the curses API in college. I figure I get a few good days every
couple of months (I do
have to work). If I were to spend less time emailing and chatting, I
could obviously get more work
done. I think that sometimes, the productivity and emailing goes hand
in hand.
> Firstly I'd like to get a reference to the desire on the part of
> "they" (the Open Croquet/Squeak
> developers) to use capabilities for their security. However, when
> looking some at:
>
Well, I think I saw a presentation online where Alan Kay mentioned it.
> http://www.opencroquet.org e.g.:
> http://www.opencroquet.org/Croquet_Technologies/architecture.html
>
If you search for "capabil" on this web page, I think you'll find three
(probably really just one or two)
references, one mentioning E.
> and seeing comments like:
>
> "The Croquet Project seeks to enable the world-wide complex of
> networked computers function
> like an infinitely fast and capacious error-free computer with no
> communications delays.
> This complex would provide wide simultaneous realtime safe access and
> authoring to very
> large object-bases running from very data-like holdings such as
> banking and other financial data,
> to immersive virtual environments of many kinds, to complex
> simulations involving thousands of
> computing elements."
>
> it makes me think that if you want to incorporate capability
> technology into a development
> like the above then you need to function at a higher, network level.
> That being the case
> I would suggest considering incorporating YURLs into Croquet. That
> is, make YURLs the
> network authority tokens, "capabilities", that you use for internal
> communication within
> Croquet. Doing so would seem to me to allow very convenient POLA
> communication
> across the Internet - as seems the intent of Croquet.
>
Yes, currently many Squeaks and Croquet ride "above" the operating
system. It should run on
any OS that supports Squeak and a higher rev of OpenGL (1.4 I think).
From the squeak
web page:
"Squeak is available for free via the Internet, at this and other sites.
Each release includes platform-independent support for color, sound, and
network access, with complete source code. Originally developed on the
Macintosh, members of its user community have since ported it to
numerous other platforms including Windows 95 and NT, Windows CE (it
runs on the Cassiopeia and the HP320LX), all common flavors of UNIX,
Acorn RiscOS, and a bare chip (the Mitsubishi M32R/D)."
Note that if it runs on a bare chip, it will qualify as an operating
system, I think. I do not know how the Squeak
virtual machine protects portions from other portions. I suspect it is
done through object references, since Squeak
is essentially Smalltalk. I don't know how suitable Squeak is to turn
into a capability language. I imagine the basic
security will be based on the portal. If you give someone a reference
to a portal, then they can enter that world.
I can see how that reference could be encoded in a YURL.
I read that it is getting difficult to run Croquet on UC campuses
because they are restricting ports on the firewalls.
Perhaps with a capability based system we wouldn't need firewalls at
all. I think getting rid of firewalls is one of Alan
Kay's visions.
Actually, I found out about Open Croquet by following links off web
pages listed on this emailing list.
> If you were to incorporate YURLs (essentially "password" capabilities
> - a slight weakness
> that I believe can be remedied in the long run) into Croquet and
> support it on today's
> commercial systems (Windows, Unix) you immediately get POLA authority
> management
> across the Globe among billions of people for your Croquet
> application. If you were to port
> Croquet to EROS you would get IPC level efficiently in POLA authority
> management
> for perhaps some hundreds of people who happen to run EROS. I know
> which I would
> choose.
I may have trouble convincing the Croquet authors that a YURL solution
fits in the post web
era. But I can certainly try. In fact, I think I've already mentioned
it on their email list.
How does a capability system prevent replays on the network? What does
this mean financially?
Note that Croquet can still run native apps. So there can be a
transition where you are half
POLA, and half unPOLA. Poca Pola? Pepsi Pola?
John
More information about the cap-talk
mailing list