Hi, Steve. Thanks for your thoughts; comments inline.
Steven M. Bellovin wrote:
> That firewalls should be omitted is no surprise. A
firewall is a
> device for centralized policy enforcement; it's useful
when policy to
> the "outside" -- whatever that is -- is
different than policy for
> the "inside". If you don't have a
well-defined "inside" and
> "outside", they're not very useful.
The "no firewalls" thing is really a journalistic
misrepresentation.
There are no *personal* firewalls, in the
keep-popping-up-messages-and-prompts sense. P_NET filtering,
described
in the spec, is implemented exactly by using a firewall --
standard
Linux netfilter. Because each program executes in a VM of
its own,
enforcing network access policies on it becomes very simple:
it's a
matter of choosing to NAT or not NAT packets from/to its
virtual IP,
with any applicable restrictions.
But it's no longer something the user has to know or care
about, which
has been one of my fanatical focuses in designing Bitfrost.
I firmly
believe this is how most security systems should be designed
regardless
of the target audience, but with 6 year olds in the mix,
it's no longer
a belief or convenience, it's an absolute necessity.
> Even if the crypto authentication succeeds, all it
means is that some
> process on the other machine has access to the
credentials; it says
> nothing about whether or not the human in front of that
machine wants
> to connect.
Is this a general comment, or are you talking about some
particular
crypto authentication on the OLPC?
> It would take a fairly radical OS design to
> prevent a user-level worm from spreading.
Is it really a big deal if a worm spreads to every OLPC
laptop, but
can't do anything particularly malicious once it's there?
> Thought experiment:
> explain what OS facilities would have prevented the
1988 Internet
> worm from succeeding.
If you said "spreading," I'd have a different
answer. But let's talk
about the worm succeeding. It "succeeded" in
bringing down the Internet
because it -- accidentally, from what we know -- kept
creating running
copies even on previously infected machines. Eventually
there were too
many processes, and the machines buckled under the DoS. The
Morris worm
amounted to a self-propagating forkbomb.
Bitfrost would keep the Morris worm from
"succeeding" in any interesting
sense. Assuming the worm managed to spread despite the
other
protections, once it landed on a user's machine and the
processes
started multiplying, they'd just get throttled back -- to no
more than
10% CPU use -- for the combined lot of them -- if the user
doesn't have
the worm's window in the foreground of the UI. (What window?
Exactly.)
Decoupling user permissions from process permissions and
integrating
explicit assent into dealing with the user's documents get
you a long,
long way towards a usable and reasonably secure system, I
think. If I'm
wrong, I'll have 10 million reasons to not sleep next year.
--
Ivan Krstić <krstic solarsail.hcs.harvard.edu> | GPG:
0x147C722D
------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com
|
