AntiVirus?

[Mike Hearn]

On Sun, 20 Mar 2005 18:47:41 -0500, Gregory Maxwell wrote:
> The commentary there on the lack of signing is a little weird....  If
> I setup a mirror repo, people need to trust *me* to use it unless the
> packages are signed.. 

Ah well the context of that FAQ is for a distributed 3rd party
installer/package hybrid system. So there are no repositories. Projects
like Gaim can (and do) provide their own binary packages independent of
distributions. So, while you *can* sign packages, without some web or
heirarchy of trust it means little as they will typically be mirrored only
by SourceForge or somesuch ...

It doesn't mean we won't do it, it just means it needs careful thought and
implementation.

> Hah. No, I meant that you might as well reformat/reinstall because the
> rootkit is so darn hard to remove, pointing to the futility of
> antivirus type techniques (esp generic ones).

Ah well, yes. But only if there are kernel exploits, I guess. 

> Since it's already there, and it's clear that it will be much more
> useful prior to the arms race (you argue that it will be somewhat
> useful after the arms race, I argue that it will not be useful at
> all.... Time will tell, I suppose) why don't we allow those that need
> the highest level of protection install it themselves now and get the
> benefit of the full pre-arms race gain, ... and only make it a default
> once it's clear that it's needed.... Maximizing whatever gain it has,
> and giving more time for better security measures to be created.

Hmm. I guess that makes sense. If it becomes clear that it's needed
installing it by default is not a hard change to make.

> It's not going to find very much, really, perhaps if coupled with a
> pretty good regression suite with random test cases. :)    Source code
> analysis has a lot more potential, especially if you're working with
> the assumption that the original code is secure and you're just
> looking for patches that break it.

OK. I don't know much about that type of analysis.

> The problem is that you'd only want to whitelist audited code.. And
> with the pace of development it's not clear that it's reasonable to
> keep enough code well enough audited to warrant such a system....

In the FAQ/NOTES file I argue that it's better to be liberal with
whitelisting and then have a good revocation system. IOW it's more about
stopping people once they proved untrustworthy rather than attempting to
ascertain the danger of their code beforehand. Once user reports of "this
program is spying on me!" start rolling in you can revoke those packages.

> Refactoring apps, apis, and user expectations to accept running most
> applications in a highly jailed environment... plus improving the
> performance and scalability of our jails would be a good step in this
> direction. i.e. why does gaim need to access any of the file system
> outside of ~/.gaim? ... The only obvious exception is file transfers,
> ... the file transfer system could work by having another little
> program that poped up and asked for which file, and communicated over
> a socket back to the more heavily jailed gaim... The file program
> could be simple enough to be proven secure (if not for the fact that
> it must call GTK).

Yes. That is sort of the theory behind SELinux. Splitting programs into
multiple components like that is what my 3rd year dissertation will be on
(just have to get it approved, pretty likely to happen). More
specifically, it's on a fast local form of RPC that requires minimal code
changes - sort of a more generic form of what Colin Walters has been
doing with imsep except for any library or sub-module, not just gdk-pixbuf
loaders.

> But getting developers and users to understand that they need to build
> their apps in this way when the can is a huge challenge...  Getting
> selinux to scale to supporting several different finegrained security
> policies for every application on the system, much less getting the
> selinux aware package maintainers to scale, will be a challenge as
> well. :)

Oh yes, there's a lot of work still to do :)

thanks -mike