Linux-Development-Sys Digest #151, Volume #7 Sat, 4 Sep 99 01:14:16 EDT
Contents:
Re: Flamage - Why? (Peter Samuelson)
Re: select() and FD_SETSIZE (Peter Samuelson)
Re: TAO: the ultimate OS (Peter Samuelson)
Security, or Lack Thereof... (Christopher B. Browne)
Re: TAO: the ultimate OS (Christopher B. Browne)
Re: TAO: the ultimate OS (Peter Samuelson)
Re: Flamage - Why? (Christopher B. Browne)
The Conceptual .Signature (Christopher B. Browne)
Re: TAO: the ultimate OS (Peter T. Breuer)
----------------------------------------------------------------------------
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:54:59 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[James Andrews <[EMAIL PROTECTED]>]
> I was merely annoyed that you seemed to discount ideas that we intend
> to implement as "impossible" somewhat unduly. When my father was
> younger he read an article in a paper, and ran to tell his parents
> that he thought men were going to walk on the moon. They laughed at
> him, and not a polite chuckle either, they bellowed till their ribs
> hurt. About five years later, the article was proven correct, men
> walked on the moon for the first time. If you asked anyone in the
> world, in 1964 whether man could ever stand on the moon, they'd
> almost certainly say "No", and that it was impossible.
This is a bad analogy. It would be a good analogy except that you seem
to be failing to take into account the difference between laymen and
professionals/academics. You are talking about laymen. Laymen often
believe things to be impossible which are in fact being developed
already, or believe things to be imminent which in fact researchers
have given up on as either too difficult for the current state of the
art (cf. human travel at relativistic speeds) or as a waste of time
because of known issues (cf. turning lead into gold). Professionals in
1964 did not believe walking on the moon was impossible. Professionals
in 1944 might have believed this, but that is a different thing.
For R&D purposes it is safe to equate "impossible" with "not likely to
be practical in the next X years" as both translate to "waste of time
to work on today". In the OS design field I submit that X is probably
betwen 8 and 15 years.
On Usenet you are generally dealing with some laymen, some crackpots,
and some professionals. None of us have any idea who is who, except by
inference from prior posts, but those prior posts lead me to believe
Chris Browne is one of the professionals -- someone who has evidently
seen and used enough OSes and enough hardware to at least have a good
idea what is possible and what is not, what is practical and what is
not, what smart people have tried and given up on already and what they
have not.
VZN is harder to place, since he seems to have some background in OS
research -- enough to know the buzzwords -- yet he displays a
surprising amount of naivete when it comes to defining any design
specifics and overcoming design issues. Again and again, when someone
raises valid objections to his ideas or specific statements, we are
told that, though there be no evidence out there *yet* to demonstrate
how an issue is overcome or made moot, his OS will somehow take care of
it. As I said elsewhere in the thread, he argues largely by fiat.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: select() and FD_SETSIZE
Date: 3 Sep 1999 22:23:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[John Hughes <[EMAIL PROTECTED]>]
> What part of "dynamically allocate and copy the contents" does
> realloc *NOT* do?
The "copy the contents" part, if the right piece of virtual memory
happens to be free. [Implementation-defined, of course. Any given
malloc suite might or might not do this optimization....]
--
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:13:56 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> but it seems rather paradoxical. I presume such sniping went into the
> development of linux from the beginning.. maybe thats why it took
> something like 6 years for it to cohere..
Actually no. Linux got its start because Linus wrote *all* the
original code. He had a *working* prototype (very crude but it booted)
before it ever saw the light of day. *That* is what got other people
interested. It wasn't "Hey guys, I want to write an OS, anyone wanna
help?" but "Hey guys, here's an OS I've started, anyone wanna help?"
BIG difference.
As far as I can tell the only one who has ever invented something by
imagining it is God, and most people in this newsgroup probably don't
believe he did either.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Security, or Lack Thereof...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:23:38 GMT
On 4 Sep 1999 02:27:30 GMT, Vladimir Z. Nuri <[EMAIL PROTECTED]>
posted:
>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.
False dichotomy? Or are you merely in a state of denial that the
problems researchers have found to be problems actually are problems?
>: 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.
We already know where this takes people; this sort of security scheme
has been in place in mainframe environments for many years now, with
Top Secret and the likes.
These sorts of environments require an army of security administrators
to set up the capabilities appropriately, and to fix things when they
break, which inevitably does happen.
>: 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)
Dennis Ritchie's award winning paper entitled "Reflections on Trusting
Trust" debunks this; it establishes a "trojan horse" methodology that
cannot be avoided, and where the evidence goes back to roughly the
late '60s or early '70s.
>: 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..
Does that mean that we can peg you as a clear disadvocate of
maintenance of privacy?
- If I write a spreadsheet, *I* must control whether it is released
from my PC to someone else's, or not.
- If I enter personal accounting information on my system, I don't want
that data published in public.
- If I type in credit card information into notes on my system, I don't
want any processes grabbing that data and emailing it out to
email.frauds.r.us.org.
If you consider that protecting the privacy of information is only of
importance to defence contractors or the NSA, that certainly shows where
your priorities are...
>: 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).
Those with infinite faith in the notion of sandboxes to solve All
Possible Security Problems should certainly join you.
It should certainly be taken offline, as it doesn't belong in
alt.os.linux, comp.os.linux.advocacy, comp.os.linux.development.system,
or comp.os.misc,comp.unix.advocacy.
>: 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"
Hand waving isn't good enough. Proving the security of systems is as
much a task of mathematical analysis as it is anything else. That is
precisely the implication of the A1 level defined by TPEP.
Given a clear set of definitions (which are lacking here) it is possible
to then establish a set of starting states (which are lacking here),
transformations (again, lacking), and "security faults," (lacking)
and then analyze the system to see what transformations do and do not
result in security faults.
See virtually any of the papers by Bruce Schneier of Counterpane Systems
or his well-received book for a systematic set of examples and analyses.
It's POSSIBLE that monkeys will fly out of my butt; that is probably about
as likely an outcome as your confidence resulting in a secure system.
--
cc hello.c, in Canada, results in:
eh.oot
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/crypto.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:40:32 GMT
On 3 Sep 1999 23:07:11 -0500, Peter Samuelson <[EMAIL PROTECTED]> posted:
>[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.
Remember that the further away from the equator the backup is, the more
likely it is to be a cold boot.
--
Rules of the Evil Overlord #90. "I will not agree to let the heroes go
free if they win a rigged contest, even though my advisors assure me
it is impossible for them to win."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.ntlug.org/~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: TAO: the ultimate OS
Date: 3 Sep 1999 21:46:17 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[me]
> > > [Theodore Y. Ts'o <[EMAIL PROTECTED]>]
> > > Ted T'so
[Nix <$}xinix{[email protected]>]
> > I'm sure this indicates something.
> > Maybe just `Ted's name is hard for the plebs to spell unless we
> > have a pronunciation guide' ;)
[Vladimir Z. Nuri <[EMAIL PROTECTED]>]
> or, maybe it is just a typo.
Nope. As original author, I confirm that it was not a typo. I have
always written "T'so", never noticing that it was wrong. Until now.
Now I've got it straight. (:
> oops, I forget. on usenet, never give anyone the
> benefit of the doubt. always give them the wrath of hostility.
What's the matter, feeling persecuted? (:
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Flamage - Why?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:40:31 GMT
On 3 Sep 1999 22:57:56 -0500, Peter Samuelson <[EMAIL PROTECTED]> posted:
>[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?
We have to make sure that the research is quoted rightly...
"They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan
--
42
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: The Conceptual .Signature
Reply-To: [EMAIL PROTECTED]
Date: Sat, 04 Sep 1999 04:59:29 GMT
On 3 Sep 1999 23:26:10 -0500, Peter Samuelson <[EMAIL PROTECTED]> posted:
>[Christopher B. Browne <[EMAIL PROTECTED]>]
>> [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>
>
>Is that how many you have? Wow. Obviously you have been collecting
>quotes for awhile.... Oh, and let me take this opportunity while I'm
>already offtopic to congratulate you on the average quotability index
>((2*wit+insight)/3) in your collection. Also, can we assume the
>unattributed ones are your own?
There's 100 of 'em that are "Rules of the Evil Overlord;" others
have just accreted over the years. They tend to collect in spurts;
on occasion I've run into some lists of "Fortunes" just too good to
leave unused. Not all are true; the ones that are definitely false are
too entertainingly controversial to leave out.
The one below is from a recent set of "pearls" from the late Alan
Perlis who was the first head of CMU's CS department, first President of
the ACM, first Turing Award winner, and the creator of a whole pile of
*wonderfully* quotable epigrams. <http://www.cs.cmu.edu/csd/perlis.html>
It would be a severe shame for them to be forgotten...
"The debate rages on: Is PL/I Bachtrian or Dromedary?" - Alan Perlis
I have tried, where possible, to attribute them; I tend to actually
attribute myself where it is something I know I initiated. That is
arguably a tad arrogant, but only forcibly hits a very small fraction
of them. If it doesn't have any name beside it, I probably couldn't
find an attribution. (Or perhaps didn't look...)
(On one entertaining occasion, someone asked me if the quote was true,
and I wound searching out a ZD columnist and asking him if the quote
purported to be his actually was. It was, and I'm quite sure all three
of us were entertained by the experience. It's in my mail archives
someplace...)
>P.S. "compatibility". Three I's, one A.
Will have to fix that... Thanks...
--
Rules of the Evil Overlord #49. "If an enemy I have just killed has a
younger sibling or offspring anywhere, I will find them and have them
killed immediately, instead of waiting for them to grow up harboring
feelings of vengeance towards me in my old age."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
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 04:01:47 GMT
Reply-To: [EMAIL PROTECTED]
Vladimir Z. Nuri ([EMAIL PROTECTED]) wrote:
: In comp.os.misc Peter T. Breuer <[EMAIL PROTECTED]> wrote:
: : My comment was that the proof is valid even in the presence of the
: : sandboxing concept. The proof goes through when the system is arranged
: : in hierarchies. You can't write a program that will reliably detect a
: : virus, even if you can execute that virus in a sandbox so it doesn't
: : harm you. Any program that detects some viruses must fail to detect
: : others (notably the trojan constructed in the proof).
: I disagree. the whole concept was that you were writing a program
: that called a subroutine, "call virus checker on program Y".
: if the virus checker
: subroutine cannot be called from within that program (proof hierarchy,
: axiomatic system etc) then it does not exist. it is undefined
But that's what the proof shows! It's a proof by contradiction. I.e.
(1) assume that a virus checker program exists, (2) derive a contradiction,
and (3) deduce that it does not exist.
You say that the derivation of the contradiction is invalid. But you say
so claiming that we cannot call the program whose existence we desire
to refute. Sorry! A program you cannot call is precisely a non-program.
One of the properties of programs is that they can be called. They're
specific lengths of machine code. If you truly don't know how to call
them as a subroutine (push a a stack frame, put the return address on
the stack, etc.) just copy out the code longhand and compile it.
: by the way, if anyone wants to look this up, I think the
: title of the article was "there are no perfect virus checkers"
Indeed. Any program that finds some viruses must miss some.
: in the american mathematical monthly, early 90s..
: I wrote a nastygram to the author when it was published.. big hint on my
: identity.. hehhee
Now why would you want to hide your identity ... ?
--
Peter
------------------------------
** 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
******************************
