Re: Virus free desktop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Giving remote user interactive access to your system doesn't really
differ from what the virus can do itself, it only gives interactivity to
use the system's CPU, memory and disk space. I think there's already p2p
applications that you could willingly run and let other people do this
to your system..

Anyway, the important thing here is that if you know a program is
running, you're expecting it to do something useful or you close it.
After it's closed, it doesn't run anymore and can't do any of the
potentially harmful things. So basically if you wish to create some
long-running floodbot, you have to create an application that user
actually wants to run for a long time. A game maybe.

> 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.

> The big issue would be network/internet access, not normal I/O (at least
> these days it is).  Maybe something that allows the OS to intercept any 
> port calls (ie: open(), bind(), etc) and check to see if they are
> allowed, or allowed by the particular application (which is in turn
> checked against an md5sum fingerprint kept in a central location).
..
> I know there is a system in development by a friend of mine for windows 
> which has similar functionality to this.

I remember seeing a few papers discussing how these could be
circumvented.

> 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..

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 agree it's off-topic here, future discussions to
secureos@xxxxxxxxxxxxx please (which was Cc'd originally..)

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Fedora Desktop]     [Trinity Users]     [KDE]     [Gimp]     [Yosemite News]

  Powered by Linux