> In these scenarios, the old adages of "don't run code from untrusted
> sites" and "only open attachments from people you know" don't help.
"Don't ever run any executable that wasn't signed by trusted party, or
compiled from signed sources from trusted party, or installed
from trusted physical media". There is absolutely no excuse for having any
executables in casual exchange between untrusted parties.
> Recently, the RingZero trojan behaved as in endgame 2 - mapping web proxy
> servers and returning results to Russia.
That means, you still have to configure your client to use compromised
proxy.
> It is still active - watch your
> port 3128,8080 logs. I also remember an ssh or tcpd tarball being trojaned
> for a few days a while ago, as in scenario 1.
>
> The problem, then, is how to authenticate code before it makes system
> calls - writing to disk, or using the network. RedHat's RPM, with GPG/PGP
> signing of packages, is one way to avoid installing a tainted package,
> but doesn't address the other infection vectors.
>
> I wondered if it were possible to do something like compute a checksum
> of images before running them and compare with a database of digitally
> signed checksums, or do the old VMS thing and assign images network
> privileges. I had thought to write a daemon that occasionally runs through
> /proc/*/exe and checks things.
What for? I can understand why someone may want to restrict the ability
of processes to do something with the network, but why check the
executable? If executable is owned by root, and it's changed, it's too
late to do anything -- whoever will check it, will probably be replaced
already unless something very complex (and annoying, and hard to
use, and reducing useful functionality such as PCMCIA support) like
securelevel will specifically prevent it. If user is running something,
what will it be checked against? Something owned by the same user and
therefore compromised at that time? Something not writable by that user,
and therefore impossible to maintain?
> It occurs to me that the Java community has been through all this already,
> though I get the impression that signing of objects is pretty rare still,
> and the tools I had seen for signing Netscape applets were commercial.
Java only provides signatures to prevent most blatant trojans, and in
most cases it doesn't work well. Say, a user got something that has no
signature, and it needs some privileges to run -- what is he supposed to
do after he will see an error message?
>
>
> thoughts ?
> ideas ?
> "been there, done that" ?
I see only one solution -- elimination of the need to run _anything_
that can possibly modify user's files and have unrestricted network access
in the casual exchange of information. If everything that runs is either
trusted (executable installed with proper checks of the package from
trusted source) or has its own sandbox (similar to what Java has for
applets, but implemented reliably) not shared with any other applications,
there will be no trojans, viruses, etc. If not, they will exist despite
whatever checks someone will try to use.
In the particular case of spreadsheets, applications most prone to
mismatched security requirements of the environment and necessary
capabilities of "code" in them, I once proposed the model where
spreadsheet is distributed as a file with three sets of data -- original
data, code that when applies to original data produces working
spreadsheet, and data snapshot (complete or as a difference between
snapshot and original data) made by the application of code in the
spreadsheet to its original data in the sender's environment (or in the
environment on some server that is supposed to execute it if the
spreadsheet uses the model where environment is hosted on the remote
server).
Then if user does not trust received spreadsheet as an application
(given that "code" in the spreadsheet needs some privileges to run -- this
is the case in most of spreadsheets now) he can just refuse to run it and
will see the data snapshot. Snapshot shows exactly what was the result of
running it in the sender's environment, data will still be accessible to
all operations, but actual code that produced it won't actually be
running, and user won't be able to do anything interactive except
operations that he will request explicitly or that are contained in the
trusted spreadsheet applications that he has already.
-- Alex---------------------------------------------------------------------- Excellent.. now give users the option to cut your hair you hippie! -- Anonymous Coward
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/