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 procontrol fi please (which was Cc'd originally..)
Attachment:
signature.asc
Description: This is a digitally signed message part