Re: Virus free desktop

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2003-11-18 at 17:24, Timo Sirainen wrote:
> On Tue, 2003-11-18 at 22:38, Alan wrote:
> > A couple of thoughts.  Some viruses are not viruses per-se, but
> > legitimate programs acting in a way that is undesirable.  IE: something
> > that opens up a connection to IRC, or a mail relay, or a login.  This is
> > something that could be wanted, but it's when it's started without
> > knowledge of the user it becomes a problem.
> 
> Yes, networked access is problematic. However I don't think it's such a
> huge problem. Mail relay is nowdays really bad - that's why I separated
> outgoing SMTP from rest of network access, making it a privilege not
> given to applications by default. Connecting to IRC or in general
> flooding some other networked systems is .. well, not good of course but
> I wouldn't say it's all that important either compared to what viruses
> can do now.

except that port in no way means anything.  it takes two seconds to make
my mail server listen on non-standard ports.  indeed, *many* servers do
this, for things like proxy servers for spam/virus catching, working
around ISP anti-server blocks, and so on.

if you want to stop SMTP, you'll have to scan the actual connection, and
parse it, and see if its SMTP, in the kernel.  of course, now you also
have to see if they are telneting to a remote host and piping output to
sendmail on that machine, or piping to sendmail on the local machine, or
dropping mail in evolution's outbox, or any other of the myriad of ways
to send mail.  you can add all this special cases (which is really bad
practice to begin with) and you'll never stop the problem.  virus
hackers will just work around them like they work around every other
existing security precaution.

> > Running programs in a sandbox or letting the OS decide what is or is not
> > a virus would require some sort of database for the os to look up a
> > binary fingerprint, or do some sort of heuristic check to see what the
> > app or docuement is doing, and if it's allowed.  It would have to know
> > that ssh starting up is different than a user (or root) executed program
> > that opens up a port that allows incoming connections.
> 
> I don't want to go this far. This is guessing and while it may help some
> I think it's way too much trouble to be useful.

this is basically what TCPA lets the OS do, iirc.


> > Now that all said, this is more an OS function than anything to do with
> > gnome, unless you're going to build this functionality into gnome itself
> > (hard to do I think without OS support).  Course, I'm just talking out
> > of the side of my head here :)
> 
> Well, it's really interaction between kernel, some new services, X
> server and desktop applications. I think it's relevant to GNOME in a way
> that it mostly needs a user friendly interface to interact with GUI
> applications. With a few GTK/GNOME library changes it should be possible
> to implement it for normal applications. Then it'd need widely accepted
> standards as to how the application would announce what privileges it
> needs, etc..

And what about portability?  GNOME runs on a hell of a lot more than
Linux.  And it has to stay consistent between the different platforms it
supports, too.

> 
> Mostly I'd just want to find people who might be interested about
> getting it actually designed and implemented. Or alternatively people
> who would tell me why this idea can't possibly work in which case I'll
> forget it.

I've been trying.  ~,^

> 
> I agree it's off-topic here, future discussions to
> secureos procontrol fi please (which was Cc'd originally..)
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.