Hi!
On Wed, Dec 05, 2007 at 12:15:01PM -0500, bofh wrote:
>What are the risks you are trying to address?
One risk would be the plans of "online surveillance" of computers e.g.
in Germany. One way to install surveillance even on OpenBSD would be to
actively interfere with the internet connection with the surveilled
person, in the man-in-the-middle sense, and inject trojanned code
("Bundestrojaner") into the updates of the victim.
Using OpenBSD CDs doesn't protect the victim from attacks like that
that much because many people need ports/packages and to get fixes one
virtually has to use -current most of the time, and to update -current,
one often uses snapshots over non-secured transfers (ftp, rsync, source
via cvsync/cvsup). The only exception I know of is anoncvs via ssh,
but then, the CDs, IIRC, don't even ship with a known_hosts file for
the anoncvs servers.
As the talk about those "online surveillance" plans includes talk about
tailored attacks for each victim, they could investigate which OS one
uses and which ways of updating, so they could tailor their attack
vector appropriately.
Yes, *I*'d be vulnerable. I'd be not if I had a public key (and anoncvs
known_hosts file) from CD, perhaps also cvsync with cryprographic
integrity protection and public key (fingerprints) from CD, etc.
So the "online surveillance" stuff would perhaps not only affect Windoze
boxen as some people would come to think, even though the installation
of a trojan is, of course, usually much easier for Windoze than for
OpenBSD (or even a Linux installation if people with some skills operate
them).
Yes, of course cryptographic integrity protection wouldn't secure
OpenBSD against all kinds of attack vectors, but against *some*. Yes, it
comes at a cost. And I don't know whether the cost is really worth
while...
But I question whether it's really sound to just dismiss it beforehand.
>[...]
Kind regards,
Hannah.
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Arjan van de Ven | [Announce] Development release 0.1 of the LatencyTOP tool |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 020/196] IDE: Convert from class_device to device for ide-tape |
git: | |
| Tantilov, Emil S | RE: [PATCH] net: sk_alloc() should not blindly overwrite memory |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
