Linux-Development-Sys Digest #150, Volume #7 Sat, 4 Sep 99 00:14:21 EDT
Contents:
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: The conceptual sandbox? ("Vladimir Z. Nuri")
Re: The conceptual sandbox? (Jonathan Guthrie)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Jesus: the ultimate OS (Rob Churchill)
Re: The conceptual sandbox? (Christopher B. Browne)
Re: The conceptual sandbox? (Christopher B. Browne)
Re: Flamage - Why? (Peter Samuelson)
Re: TAO: the ultimate OS (Peter Samuelson)
----------------------------------------------------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 4 Sep 1999 02:28:57 GMT
In comp.os.misc Nix <$}xinix{[email protected]> wrote:
:> [Theodore Y. Ts'o <[EMAIL PROTECTED]>]
:> Ted T'so
: I'm sure this indicates something.
: Maybe just `Ted's name is hard for the plebs to spell unless we have a
: pronunciation guide' ;)
or, maybe it is just a typo.
oops, I forget. on usenet, never give anyone the
benefit of the doubt. always give them the wrath of hostility.
hehe
when in rome, do as romans.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 4 Sep 1999 02:27:30 GMT
In comp.os.misc Theodore Y. Ts'o <[EMAIL PROTECTED]> wrote:
: There's another tradeoff; between security and ease of use. The
: question is, how do you configure your sandbox? You either ask the user
: to configure it, in which case you lose because the user won't know how
: to answers the questions correctly, and it will be horribly complex or,
: you can ask the program which is running, which you can't do because
: it's not trustworthy.
imho more false dichotomies. there is a consistent belief by
programmers that you can't win when dealing with novice users.
programmers, remarkably, many of whom have worked on open
source projects, have some of the most elitist attitudes
on the planet.
to add to my assertions about a virus proof OS, I believe it
can be secure yet user friendly. I think it is poor design
that makes security so complex on existing systems. typically
security is added on top of capabilities. but all capabilities
need to be designed with security in mind. security is
a kind of anti-capability that is as important as capabilities.
a concept not understood by most engineers who think in
terms of "who can I do [x]" not "how can I do [x] while
constraining [y]"
: You could posit that the OS could look over the code and figure how the
: sandbox should be configured based on what the requirements of the
: applet are, but how does the OS determine what are legitimate
: requirements and what are bogus requirements? Sure you can block out
: really obvious ones, like "I need raw access to the disk so I can format
: it", but more subtle ones like the application claiming "I need write
: access to the spreadsheet so I can update some data" --- is it really
: updating data, or is it destroying data? Or is it installing an
: application macro virus? Having the OS figure it out without asking the
: user is tantamount to trying to solve the halting problem.
bzzzzt totally (respectfully) disagree on this. I believe
a robust security system is possible with a different
granularity other than those that currently exist. it is
not so much file-oriented anymore but object oriented.
it keeps track of what objects (apps) own other objects.
this is a parallel security system that works in tandem
with the security related to individual users. in fact
each user in a sense has their own sandbox, and each
application has its own sandbox, and their are
sandboxes within applications, etc.
: The other approach which has been tried is code signing --- but that
: assumes that the code signers are trustworthy.
I think code signing is part of the solution but has
been implemented poorly. I think it is appropriate that
some utilities are signed, such as system level ones,
but one should also permit "anonymous" applications
that can run without harm, but may be limited in
function (e.g. not allowed to format hard drive)
: The final observation I will make is that Vladimir's "we'll just make
: some files read-only" also shows an amazing amount of naivete.
: Read-only compromise (of strategic planning data of a company, for
: example) can often do just as much damage as other kinds of damage ---
: after all, even if a virus destroys your data, assuming that you have
: competent sysadmins, you'll have backups. But with a read-only
: compromise of sensitive data, you may never know what hit you until it's
: too late.
I don't understand what you are talking about. what is a "read-only
compromise of sensitive data"? I think you are talking about
an entirely different kind of security, i.e. that you don't
want to divulge certain kinds of information.. but in fact
this is a ridiculous requirement of an open OS system.. or
at least it is a much higher standard than anything that
we are interested in, that few entities other than defense
contractors and the NSA are seriously interested in right now..
: But, as I started this whole posting with ---- this completely begs the
: question of how do you configure the sandbox in the first place? How do
: you know which files (or objects) an application should be given write
: access, and to which an application should be only given read access?
: What (if any) network connections should the application be allowed to
: open? Is the application allowed to throw up a window? Is the
: application allowed to grab keyboard focus? So many questions --- and
: no way to answer them securely.
I absolutely disagree (respectively) that there is no elegant way
to handle all these issues. I do agree that it has been poorly
handled to date, and judging by existing systems, it is
an impossible problem. I'm saying the sandbox concept is the
place to start. I'm saying I want to hash out the details with
people who agree it is possible. for those who do, please
sign up for the mailing list (details below).
: Not specifying such troubling, niggling little details is part of the
: hand-waving and arm-waving which is going on here.
there are lots of difficult details. its hand waving and
arm waving. I'm saying its POSSIBLE. for those who agree with
me, I am confident we can work out the details. "let's do it"
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Date: 4 Sep 1999 02:41:59 GMT
In comp.os.misc James Andrews <[EMAIL PROTECTED]> wrote:
: Hmm, I dont think you can change the definition of a virus, that seems a
: little absurd.
respectfully, you guys just are not getting it. there are two
very distinct definitions:
1. a virus is something that when run, corrupts the OS.
2. a virus is something that can potentially corrupt
the OS when run.
these are totally different programs. (1) I agree results
in the halting problem paradox. (2) does not. limiting
security to (2) does not prevent "useful" programs from running..
: too many people on this thread do not understand the
: concept properly.
agree<g>
: The conceptually ideal sandbox, as a component of an operating system,
: is actually a simple idea. In this eventuality, the sandbox acts as the
: "quarantine process", it monitors each call to operating system
: functions and tests for reasonable bounds, if these are exceeded then
: the user is asked to make a decision about the fate of the exceptional
: task.
I like this except for the idea the user is required to intervene
generally, which I consider abysmally tedious.
: The major weapon on the side of the operating system is that it is
: always guaranteed to be running first, and it should always control the
: environment of the task.
right
: Once the task leaves its own space and enters our drivers,
: the original programmer has no control, they have to respect the
: operating systems ability to perform the requested operation. At this
: point, the request can be type-tested, to ensure no foul intentions.
: With a new operating system, where functionality can be incorporated at
: the lowest conceivable level, every aspect of the system can be
: sandboxed, without much effort.
EXACTLY
: This sandboxing method is in itself a solution to the halting problem as
: each running process must request each operation, and these requests can
: be examined for a halting situation, and denied where applicable. In
: this respect, most operating systems already contain the framework to
: implement full sandboxing, but because it was not incorporated from the
: start, they would now require far too much work. This is a simple
: progression from the memory protection, user and file segregation of
: current OS's.
EXACTLY.. it was not designed in from the beginning, which is what
I am seeking to do..
: The only disadvantage of this methodology is that it assumes the low
: level functions of the implementing OS are perfect, but then, don't we
: all aim for that anyway? We cant assume we write flawless software, but
: its not an impossibility.
imho the topic of bugs in software is a totally separate debate
I am not really interested in debating.. it is a question of
how closely we can get machines to match our intent, and imho
the answer is for OS programming purposes "as close as we like"
... imho this issue is frequently mixed up in the discussion
of creating a secure os when it is really a peripheral issue.
: At the end of the day, I don't understand how so many people can sit and
: deny such a simple concept.
AMEN brother .. please please please sign up for the mailing
list. we would love to bask in the light of your wisdom.
: This is a simple example, the beauty of computers is their ability to
: perform mathematical, and logical tasks at ludicrous speeds. It wouldnt
: be very difficult to create an environemt with much more defined
: boundaries, or more "intelligent" judgement.
EXACTLY.. in all features.. not just the patchwork quilt
we have today, but a coherent blanket!!
It also wouldnt be
: difficult to make a far more confined sandbox for the first run of a new
: piece of software.
imho the sandboxes should always be active.. not merely to
test new software but the standard operating environment..
: As you can see, the sandbox idea is far from limited. Many of the
: people discussing on this thread seem to have a fixed image of a sandbox
: drawn from a substandard implementation, but the concept has far more
: scope than that discussed here, and it is a relatively simple concept.
exactly .. set up a straw man and burn it.
: Most current OS's couldnt implement one properly, because they are far
: too large, clunky and heterogeneous. They use a mash of languages and
: interfaces, and allow far too much unmonitored access. However, the
: best way to create such a system, is to embed it in a new operating
: system, from the ground up.
AMEN BROTHER!!! can I have your autograph??!?!
This way you control each and every
: component, and can ensure that the sandbox protocols are implemented
: from the very lowest levels.
oh baby
: Well, thats enough post for about 3 weeks, so I'll leave it at that,
more,more,more!! encore!!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: Jonathan Guthrie <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Date: 4 Sep 1999 03:10:13 GMT
In comp.os.misc Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
> In comp.os.misc James Andrews <[EMAIL PROTECTED]> wrote:
> : Hmm, I dont think you can change the definition of a virus, that seems a
> : little absurd.
> respectfully, you guys just are not getting it. there are two
> very distinct definitions:
> 1. a virus is something that when run, corrupts the OS.
> 2. a virus is something that can potentially corrupt
> the OS when run.
Actually, in technical usage a virus is neither of those things. A virus
is a program fragment that attaches itself to some other program so that
it can attach itself to other programs when that program is run. This is
distinct from a worm, which is a complete program whose design purpose
includes reproduction, often in an uncontrolled or a malicious fashion. It
is also distinct from a trojan horse, which is a program that is
distributed because it makes the user believe it does worthwhile things in
addition to its real, and usually malicious, purpose.
To be a virus, it is neither necessary nor sufficient for a program
fragment to corrupt anything.
I think I now understand why you think a sandbox can protect you against
viruses. It is painfully easy to eliminate the possibility of
"corruption" of the system while it is running. It is somewhat more
difficult (reference a paper, I believe by Dennis Ritchie, of using a C
compiler to propagate a trojan horse) to eliminate the possibility of
corruption of the system when it is restarted. Neither one protects you
from viruses.
--
Jonathan Guthrie ([EMAIL PROTECTED])
Brokersys +281-895-8101 http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX 77014, USA
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 3 Sep 1999 22:14:48 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> I believe an OS that is equally pleasing to the novice as well as the
> power programmer is inherently possible. I will continually reject
> the false dichotomies suggesting otherwise.
You keep doing this. Someone raises an objection to something you've
said and rather than explaining how to overcome the objection you just
wave your hand and say "I believe this objection can be overcome." You
seem to like rejecting "false dichotomies", making them false by fiat.
The sheer number and importance of things you declare true by fiat is a
large part of the reason it is difficult for many of us to take you or
your ideas very seriously.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Rob Churchill)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Jesus: the ultimate OS
Date: Sat, 04 Sep 1999 03:01:53 GMT
On 31 Aug 1999 12:47:29 GMT, [EMAIL PROTECTED] (Donal K. Fellows)
wrote:
>In article <7q1pmr$[EMAIL PROTECTED]>,
>Eric Goold <[EMAIL PROTECTED]> wrote:
>> Tim Kelley wrote in message <[EMAIL PROTECTED]>...
>>> Where is it in the bible that jesus had sex? Why didn't he?
>>
>> I THINK it may have been because he had something better to do?
>
>But they hadn't invented chocolate or computers...
>
>Donal.
>--
>Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
>-- The small advantage of not having California being part of my country would
> be overweighed by having California as a heavily-armed rabid weasel on our
> borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
I love this thread, the possibilities for trolling and general
wind-ups are limitless: but it seems a little unfair to be teasing
zealots about gnostic gospels etc on newsgroups that are after all,
for those interested in operating systems. I'll find a newsgroup where
there are more of these large slow-moving targets, and post there.
'Do thou likewise' Lk 10:37
Rob Churchill, Dept of Religions and Theology, University of
Manchester.
PS. Donal, I'm currently in the middle of changing from windohs to
linux, maybe we can meet up sometime in
[EMAIL PROTECTED] to sort out any last niggles.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:01:03 GMT
On 4 Sep 1999 03:10:13 GMT, Jonathan Guthrie
<[EMAIL PROTECTED]> posted:
>In comp.os.misc Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>To be a virus, it is neither necessary nor sufficient for a program
>fragment to corrupt anything.
>
>I think I now understand why you think a sandbox can protect you against
>viruses. It is painfully easy to eliminate the possibility of
>"corruption" of the system while it is running. It is somewhat more
>difficult (reference a paper, I believe by Dennis Ritchie, of using a C
>compiler to propagate a trojan horse) to eliminate the possibility of
>corruption of the system when it is restarted. Neither one protects you
>from viruses.
You are thinking of the "ACM Classic" entitled "Reflections on
Trusting Trust."
<http://www.acm.org/classics/sep95/>
The most salient quote would be thus:
"The moral is obvious. You can't trust code that you did not totally
create yourself. (Especially code from companies that employ people
like me.) No amount of source-level verification or scrutiny will
protect you from using untrusted code."
Note that the idea is apparently not due to Ritchie; he quotes an
unavailable Air Force paper on Multics...
"I first read of the possibility of such a Trojan horse in an Air
Force critique (4) of the security of an early implementation of
Multics. I can- not find a more specific reference to this document. I
would appreciate it if anyone who can supply this reference would let
me know."
--
"Intel: Putting the `backward' in `backward compatability'"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/oses.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: The conceptual sandbox?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:01:05 GMT
On 4 Sep 1999 02:57:40 GMT, Vladimir Z. Nuri
<[EMAIL PROTECTED]> posted:
>I am suggesting this is not an accident: in the evolution
>of the microprocessor, the concept of a sandbox arose in
>the more mature versions of it. it was not within the
>imagination or capabilities of earlier designers. but once
>the power was available, it became an inevitable concept.
That's simply not true.
If you looked at what 36 bit machines were doing between the 1960s and
1970s, you would find that from a conceptual point of view, there is
very little that is presently being implemented on microprocessors
that was not previously thought of in the context of mainframes and
minicomputers back then.
It is a far more tenable position to claim that microprocessor
implementations of questionable quality have resulted in longstanding
mainframe constructs such as virtual machines being things that could
not be implemented in a microprocessor environment.
[And some randomly selected .signatures are too appropriate for words
to express... A 1-in-777 chance rings true...]
--
"Intel: Putting the `backward' in `backward compatability'"
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Flamage - Why?
Date: 3 Sep 1999 22:57:56 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> Tao is The Way!! haha but when the ignorant and the arrogant hear of
> the Tao, they laugh & scoff. haha
Insert Sagan "Bozo" quote. I laugh and scoff at efforts to turn lead
into gold, too. Does this make me ignorant or arrogant?
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 3 Sep 1999 23:07:11 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Peter da Silva <[EMAIL PROTECTED]>]
> I guess the monarchy's royalty backup procedures were
> inadequate. They should have had an offsite heir in Martinique or
> something.
Useless without the mechanism to restore him. You can't reinstate the
heir without bootable media, i.e. an offsite army.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
