<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: The End to Computer Viruses and Spyware</title>
	<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html</link>
	<description>20 minutes into the future...</description>
	<pubDate>Sun, 20 Jul 2008 22:56:03 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Dru</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-14</link>
		<dc:creator>Dru</dc:creator>
		<pubDate>Fri, 08 Oct 2004 22:58:29 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-14</guid>
		<description>&lt;p&gt;I agree with what you say, but you don't really give a great argument on the practicality front. I could emulate a 32 bit processor with an 8 bit, but why would I want to do that?&lt;/p&gt;

&lt;p&gt;The same arguments can be made for avoiding MMU's and Security in hardware. If you think that everyone is going to just buy into a particular VM and expect that to work flawlessly, then your views
of practicality are far from reality. The reality is that people can
make that choice and they prefer the OS for enforcement than a language specific system.&lt;/p&gt;

&lt;p&gt;On the capbability based system argument, I agree. Those systems are inherently more secure. I've studied those about 10 years ago. Unfortunately, they are also very inpractical. The key goal of my proposal was to introduce a practical system that can be deployed 'yesterday'.  To this day, nobody has produced a shipping capability based OS that is ready for real use (even Eros)&lt;/p&gt;

&lt;p&gt;In short, your systems would work, but they would require a massive reengineering effort to pull off. That will not happen in the next 5-10 years.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I agree with what you say, but you don&#8217;t really give a great argument on the practicality front. I could emulate a 32 bit processor with an 8 bit, but why would I want to do that?</p>

<p>The same arguments can be made for avoiding MMU&#8217;s and Security in hardware. If you think that everyone is going to just buy into a particular VM and expect that to work flawlessly, then your views
of practicality are far from reality. The reality is that people can
make that choice and they prefer the OS for enforcement than a language specific system.</p>

<p>On the capbability based system argument, I agree. Those systems are inherently more secure. I&#8217;ve studied those about 10 years ago. Unfortunately, they are also very inpractical. The key goal of my proposal was to introduce a practical system that can be deployed &#8216;yesterday&#8217;.  To this day, nobody has produced a shipping capability based OS that is ready for real use (even Eros)</p>

<p>In short, your systems would work, but they would require a massive reengineering effort to pull off. That will not happen in the next 5-10 years.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Julien Couvreur</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-13</link>
		<dc:creator>Julien Couvreur</dc:creator>
		<pubDate>Thu, 07 Oct 2004 22:16:59 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-13</guid>
		<description>&lt;p&gt;I have to disagree on a number of the points in your reply.
I agree that NX is a good thing, and so was memory managment. But I disagree that it is required to build a secure system. You can have memory-safe systems without MMU (see http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf ) and you can have safe executables without NX (see C#, E).
In my opinion, the biggest problem with cert is that it is too much of an all or nothing, compared to capability-based security (like E, EROS,...). Because I trust Microsoft to write Notepad and Notepad is signed doesn't mean that Notepad should have access to all my data, the network and my devices. That's just because even though I trust Microsoft, Notepad may have a bug that makes it exploitable to do bad things. 
NX and MMU are good because they partition capabilities: a program can only access it's own memory space, a program can only execute instructions in memory that is not flagged with NX... What we need is to introduce this partitionning at the software level. And just because it's software doesn't mean it won't be secure enough, the same way the JVM and the .Net runtime can manage their own memory without needing help from a new memory handling chip.
Why wait for hardware solutions to come tomorrow, when we should be investigating software solutions today?&lt;/p&gt;

&lt;p&gt;Cheers,&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I have to disagree on a number of the points in your reply.
I agree that NX is a good thing, and so was memory managment. But I disagree that it is required to build a secure system. You can have memory-safe systems without MMU (see <a href="http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf" rel="nofollow">http://www.cs.utah.edu/plt/publications/ismm04-wf.pdf</a> ) and you can have safe executables without NX (see C#, E).
In my opinion, the biggest problem with cert is that it is too much of an all or nothing, compared to capability-based security (like E, EROS,&#8230;). Because I trust Microsoft to write Notepad and Notepad is signed doesn&#8217;t mean that Notepad should have access to all my data, the network and my devices. That&#8217;s just because even though I trust Microsoft, Notepad may have a bug that makes it exploitable to do bad things. 
NX and MMU are good because they partition capabilities: a program can only access it&#8217;s own memory space, a program can only execute instructions in memory that is not flagged with NX&#8230; What we need is to introduce this partitionning at the software level. And just because it&#8217;s software doesn&#8217;t mean it won&#8217;t be secure enough, the same way the JVM and the .Net runtime can manage their own memory without needing help from a new memory handling chip.
Why wait for hardware solutions to come tomorrow, when we should be investigating software solutions today?</p>

<p>Cheers,</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Dru</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-12</link>
		<dc:creator>Dru</dc:creator>
		<pubDate>Thu, 07 Oct 2004 18:29:07 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-12</guid>
		<description>&lt;p&gt;Hi Julian, let me address your points.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Sorry about the 404.&lt;/li&gt;
&lt;li&gt;It is a sign that the 'architects' out there are finally getting it with security. You need hardware to enforce proper execution. For example, where would we be without hardware memory management? We would have much more fragile systems without MMU's.&lt;/li&gt;
&lt;li&gt;See above. Even with Type safe languages, they can be exploited.
Also, if something can be done in hardware, then why not? It will
9 times out of 10 be faster than not.&lt;/li&gt;
&lt;li&gt;Anybody is allowed to sign an executable, script, or macro if they
have a trusted cert.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Data doesn't need to be signed since the hardware protection will 
stop that.&lt;/p&gt;

&lt;p&gt;If the authorities actually respond to complaints then you will find
that those certs will be revoked. Just like for SSL.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Sourceforge can sign your build for free.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;On hydra, skynet, malware... I disagree. You will need to have trust
systems to implement security. You trust Intel, so you run their processor don't you?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hi Julian, let me address your points.</p>

<ol>
<li>Sorry about the 404.</li>
<li>It is a sign that the &#8216;architects&#8217; out there are finally getting it with security. You need hardware to enforce proper execution. For example, where would we be without hardware memory management? We would have much more fragile systems without MMU&#8217;s.</li>
<li>See above. Even with Type safe languages, they can be exploited.
Also, if something can be done in hardware, then why not? It will
9 times out of 10 be faster than not.</li>
<li>Anybody is allowed to sign an executable, script, or macro if they
have a trusted cert.</li>
</ol>

<p>Data doesn&#8217;t need to be signed since the hardware protection will 
stop that.</p>

<p>If the authorities actually respond to complaints then you will find
that those certs will be revoked. Just like for SSL.</p>

<ol>
<li>Sourceforge can sign your build for free.</li>
</ol>

<p>On hydra, skynet, malware&#8230; I disagree. You will need to have trust
systems to implement security. You trust Intel, so you run their processor don&#8217;t you?</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Julien Couvreur</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-9</link>
		<dc:creator>Julien Couvreur</dc:creator>
		<pubDate>Sun, 26 Sep 2004 16:32:10 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-9</guid>
		<description>&lt;p&gt;A couple of points:
1) Your contact page on bigunix is a 404
2) Why is the No-Execute the most interesting enhancement?
3) Why assume that you need hardware to create security architecture? The same way that you can build reliable systems on top of unreliable ones, you can have a new architecture built on top of the old one, although that needs to be carefully done. For example, C# and E are written using less secure languages.
4) Assuming a code signature scheme, who is allowed to sign executables? Do you sign scripts and macros? What if data can exploit a bug, does data need to be signed too? ActiveX are already signed but people already install some that they shouldn't.
5) In the winners/losers list, you forgot to mention "Open Source" in the losers. Who's paying to get the nightly builds signed?&lt;/p&gt;

&lt;p&gt;I'd recommend watching Marc Stiegler's &lt;a href="http://erights.org/talks/skynet/index.html"&gt;SkyNet virus&lt;/a&gt; talk. You mentioned Hydra, a capability-based secure system, in my opionion capability-based programming languages and platforms have the most potential to fight this flood of malware that we're seeing.&lt;/p&gt;

&lt;p&gt;Cheers,
Julien&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>A couple of points:
1) Your contact page on bigunix is a 404
2) Why is the No-Execute the most interesting enhancement?
3) Why assume that you need hardware to create security architecture? The same way that you can build reliable systems on top of unreliable ones, you can have a new architecture built on top of the old one, although that needs to be carefully done. For example, C# and E are written using less secure languages.
4) Assuming a code signature scheme, who is allowed to sign executables? Do you sign scripts and macros? What if data can exploit a bug, does data need to be signed too? ActiveX are already signed but people already install some that they shouldn&#8217;t.
5) In the winners/losers list, you forgot to mention &#8220;Open Source&#8221; in the losers. Who&#8217;s paying to get the nightly builds signed?</p>

<p>I&#8217;d recommend watching Marc Stiegler&#8217;s <a href="http://erights.org/talks/skynet/index.html">SkyNet virus</a> talk. You mentioned Hydra, a capability-based secure system, in my opionion capability-based programming languages and platforms have the most potential to fight this flood of malware that we&#8217;re seeing.</p>

<p>Cheers,
Julien</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Dekorte</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-8</link>
		<dc:creator>Steve Dekorte</dc:creator>
		<pubDate>Fri, 03 Sep 2004 21:24:58 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-8</guid>
		<description>&lt;p&gt;The last time I looked into getting an SSL cert, it was just a matter of paying an expensive  fee. I'm not sure how this ensures that software is virus free. If it's just attaching a bank ID (and presuming the bank can locate the individual) then it may be useful in finding and prosecuting virus writers assuming 1. they are in a country with anti-virus laws 2. they're software was not infected by someone else's virus. Also, if certs are expensive, how do we prevent certs from effectively eliminating small shareware and freeware apps whose authors can't afford such fees?&lt;/p&gt;

&lt;p&gt;BTW, I like your article and think this is interesting stuff.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The last time I looked into getting an SSL cert, it was just a matter of paying an expensive  fee. I&#8217;m not sure how this ensures that software is virus free. If it&#8217;s just attaching a bank ID (and presuming the bank can locate the individual) then it may be useful in finding and prosecuting virus writers assuming 1. they are in a country with anti-virus laws 2. they&#8217;re software was not infected by someone else&#8217;s virus. Also, if certs are expensive, how do we prevent certs from effectively eliminating small shareware and freeware apps whose authors can&#8217;t afford such fees?</p>

<p>BTW, I like your article and think this is interesting stuff.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Dru</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-7</link>
		<dc:creator>Dru</dc:creator>
		<pubDate>Thu, 02 Sep 2004 23:23:44 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-7</guid>
		<description>&lt;p&gt;They could just use the same techniques that the Cert authorities use to authenticate SSL certs for web sites. There just has to be a barrier. Some may slip through, but that will be manageable and a world changing difference.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>They could just use the same techniques that the Cert authorities use to authenticate SSL certs for web sites. There just has to be a barrier. Some may slip through, but that will be manageable and a world changing difference.</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Dekorte</title>
		<link>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-6</link>
		<dc:creator>Steve Dekorte</dc:creator>
		<pubDate>Thu, 02 Sep 2004 23:18:06 +0000</pubDate>
		<guid>http://www.xxeo.com/archives/2004/09/02/the-end-to-computer-viruses-and-spyware.html#comment-6</guid>
		<description>&lt;p&gt;Hey Dru, How do software cert authorities know which code is safe to certify?&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hey Dru, How do software cert authorities know which code is safe to certify?</p>]]></content:encoded>
	</item>
</channel>
</rss>
