Slashdot Mirror

regarding your love of operating systems, check out plan 9: http://plan9.bell-labs.com/plan9/

Ken Thompson's "Reflections on Trusting Trust" is a recurrent Slashdot link but people never link to the counter argument article David A. Wheeler's "Countering Trusting Trust. It doesn't give a complete view to leave out the second article...

it is trivial to examine what is going across a network you own and disallow these kind of conspiracy theory shenanigans. If MS ever did this, you can bet your paycheck that between a few competent Windows / Networking admins they could and would determine what was going on

Not if you're an MS-only shop: "I ran a network sniffer to verify that our MS servers aren't phoning home." "Great. Sure am glad we bought a copy of NetSniff for Windows!"

It's the old "trusting trust" problem in a new form.

You obviously haven't met Glenda, The plan 9 bunny.

As described in Dennis Ritchie's The Evolution of the Unix Time-sharing System.

I still refuse to believe that eventually we couldn't make Internet voting more secure than paper ballots.

But security isn't the question. The problem is that with secure and anonymous electronic voting there is no outside way to verify that the results reported have anything to do with the votes cast. Whoever controls the system can make it report whatever results they want, and there's no way to tell if they are telling the truth or not. If your first thought is "well, make it open source," think again.

I already consider online banking to be at least as secure as ATM transactions, and I see no reason why a properly designed online voting system couldn't be the same.

The difference being that the banks (which run both ATMs and online banking sites) don't also control the money supply. If they did (e.g., if they could just create money the way the government does) we'd have a major problem. No matter how secure the process is, once it subsumes enough levels that you have know way of knowing if it's just reporting made-up numbers, you have a problem.

--MarkusQ

That 'somebody' was Ken Thompson in his acceptance of the Turing award i n 1984 (how apropos): http://cm.bell-labs.com/who/ken/trust.html The idea is that the compile can insert a backdoor into the login program when it is compiling it. Secondly, it can insert this backdoor into the compiler when it is compiling itself. The source no longer shows the infection. This is devious and fascinating.

It was Ken Thompson.

Ken Thompson did that : Reflections on Trusting Trust

Ken Thompson is no idiot.

Ehud

Somebody has to do this, so it might as well be me: Yes, the usual

This might earn me a "whoosh" but I trust those Debian guys to check the code before they build it into securely signed binary packages for me and other joes to consume. Before it reaches me the software has already had "many eyes" looking at it.

Okay, but what does that have to do with making sure your computer isn't compromised?

> and then just recompile that particular program.

Not that easy.

I think "free" as the adjective to "freedom" has been around longer than "free" as a synonym for "gratis".

Yes...but Stallman is attempting, just like George W. Bush and most American politicians I can remember, to redefine "free" to mean "restricted in the ways I want it restricted." Stallman's "free" is not free; it is just as encumbered as some piece of proprietary code, just in a different way. BSD/MIT is arguably "free" in the actual sense of the word. I'd almost say that MPL/CDDL is "free", and where it's not is a lot more reasonable than the GPL.

That being said, there is one reason to reject non-open source software: Lack of trust. Due to the code not being publicly accessible you have no way to tell what the software might do and no way to tell it doesn't damage your system except by trusting the company that made it.

Open source is trustworthy? There is no such thing as trustworthy code. Even some Gentoo ricer depends on a compiler somebody else built. The only way to verify that that bootstrapping compiler doesn't do something nasty, as in kt's case, is to rely on the goodwill of others.

You know, just like you do with proprietary software.

The idea of open source being intrinsically more trustworthy is a sham. Open source has tons of advantages in certain situations--but "trust" is not one.

Some decide it's not worth it and stick to F/OSS for their private use.

Seriously, though, I don't really care if people insist on being stupid and just using open source. But it's when they fucking brag about it, hurf-durfing that the rest of the world should twist to their personal corner-case choices (and he was doing that by implication if nothing else), they need to be backhanded once in a while.

So the general answer is no it will not be faster. This is because as a final step (the so called stage3) it compiles itself with itself. This assumes icc isn't malicious (yes I know - Trusting Trust and Countering Trusting Trust etc).

Look up trusting trust. Defects in the compiler, whether intentional or unintentional, can propagate themselves to the compiled work, even if the compiled work is the compiler itself.

This always gets me though: why doesn't this apply to C?

And if it doesn't bother you (from a security standpoint), perhaps it shoud: oblig. Ken Thompson, "Reflections on Trusting Trust." (Short and very sweet).

the malware has locked the registry against editing, sometimes even in safe mode

Registry keys are controlled by ACLs just like files are. Just change the permissions.

only way to be sure is to fdisk from orbit

That's good advice for any compromised system, not just a Windows box. See the famous Reflections on Trusting Trust paper for the frightening reason.

As for gconf - it's a fanboys' implementation of the MS Windows registry for linux except you not only have one per user but you also can do even less to modify, import and export keys than you can in the MS Windows version

More data format support is a good thing. Why the ad hominem attack though? I like how gconf keys are documented directly in the schema, how there's an API for modifying these keys, and how applications immediately respect changes made directly to the configuration. gconf has never given me trouble.

Once you get a registry hive that is too big to back up onto a floppy you can really forget about any speed increase you might have originally had from it being a hierarchical collection of data in a binary. That is where the majority of sytems using it stand.

Performance reading configuration data is a non-issue on today's systems regardless of whether it's stored in a registry hive or a flat text file.

Personally my main criticism is it is difficult to parse the registry to find where problems lie, which is where it loses in comparison to the most insane plain text configuration file I could think of.

Are you talking about parsing the registry hive files? The file format is documented. If you're talking about the APIs --- what don't you like about them? Also, any registry editing tool will include a registry-wide search function. Also, under cygwin, you can just use find and grep! What could be easier?

And speaking of insane configuration files --- sendmail.cf is pure divine revelation from heaven compared to radiusd's configuration.

Look up bootstrapping. Most modern compilers can compile themselves using a stage or two of simpler compilers

Look up trusting trust. Defects in the compiler, whether intentional or unintentional, can propagate themselves to the compiled work, even if the compiled work is the compiler itself.

Yes such amazing quality control that led to this problem, where "a Debian packager modified the source code of OpenSSL back in 2006 so as to remove the seeding of OpenSSL random number generator, which in turns makes cryptographic key material generated on a Debian system guessable".

While I would like to agree that Open Source allows for greater auditing of the software, it has been proven incorrect.

Read the paper, Reflections on Trusting Trust, here or the PDF here.
 

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.

Not to mention that having the source code doesn't exactly prove anything.

http://cm.bell-labs.com/who/ken/trust.html

But our geek cred is a little dented around here, so our marionettes content themselves with shouting down the minions of Mordor.

To the sage wit who suggested uninstalling Microsoft, I suggest also having a go at your BIOS and your Intel microcode CPU update. Then I suggest working through the 10^500 vacuum states of string theory with pencil and paper to ensure we're really as secure as we think we are.

Concerning this abusive patch, it strikes me that Microsoft has finally turned the corner from fearsome to pathetic.

... can be used across all hard disk drives, solid state drives (SSD) and encryption key management applications ...

I'm supposed to trust my crypto keys to a third party? What particular dealer do they think is supposed to supply me with the kind of crack that would cause me to find this acceptable? I didn't write the code that runs their firmware, and I didn't compile anything from their shop either (reference On Trusting Trust by Ken Thompson, circa 1984, for background).

Although a selling point indeed, people should be aware of this.

It's Ken Thompson's essay about trusting other's code. A very interesting read.

Also, Open Source does not neccisarily mean Linux.

Surely there are no other open source operating systems other than Linux!!

if by "cracked" you mean "brute-forced his password" or maybe "brute-forced him until he gave up his password", then yeah, I believe you.

Ken Thompson aside, I doubt there are purpose-built backdoors in any open source encryption project (commercial is another matter entirely).

holes that can be exploited, on the other hand, are probably a dime a dozen.

It's not very sexy, but it's fascinating and readable. I remember coming across it in Dillons bookshop, not knowing the name, and flicking through. Half an hour later, when I realised the time, I knew I had to buy it! Other books go into more exhausting detail (Knuth in particular), or cover a wider range (Knuth again!), or more modern ideas or languages. But Sedgewick is a great read, and I've been through it several times.

It covers all the basics (maths, searching, sorting, strings, graphs, and touches on FFTs and hardware and optimisation), and gives enough detail that you could go off and write some programs yourself. But more importantly, it explains them: how each algorithm works, what it's trying to achieve, how it behaves, and why. And it's because it explains the ideas so well that I'd recommend it. After every section I felt I'd learned something -- not because I had to, but for the sheer pleasure of understanding something new and interesting.

Other recommendations: Effective Java (a staggering amount of insight into the language), Thinking in Java (by someone who understands that language is more than just syntax), Deep C Secrets (again a pile of insight, interspersed with anecdotes and some rather off-the-wall diversions), Programming Pearls and More Programming Pearls (problem-solving in bite-sized chunks -- a little dated but still interesting). Plus I've already mentioned Knuth. K&R is well done, though narrow in scope. I find Design Patterns useful, but more for clarifying things I've already seen than for learning new things. I've never actually read The Mythical Man-Month, but people I respect mention it, so I'm sure it's well worth reading too!

Of course, times being what they are, especially in this field, a lot of interesting stuff is on-line. Some hat should go without saying hereabouts include the latest Jargon File, some of Eric Raymond's books, and more online documentation and archives than anyone but Google can cope with.

Other interesting articles include The Programmer's Stone, a guide to writing Unmaintainable Code, The Ten Commandments for C Programmers (annotated edition), Ken Thompson's Reflections on Trusting Trust, What Colour are your Bits?, and Guy Steele's Growing a Language.

Being able to inspect the source isn't the be-all and end-all. In some cases there may be more than you bargained for.

It depends very much on specific circumstances, of course, and with the fast progress of software nowadays you'd really need to be in control of both the compiler source and the target's source to pull this off. But the possibility is there.

Indeed, can one really trust any software unless written by yourself these days? Should a back door have been introduced into a compiler 5, 10, 20 years ago, it's effects could still be around today...

As implemented by Ken Thompson

What makes you think they haven't got a contract with Microsoft for access to the source code ?

Even if they do, unless they compile the source code themselves with a compiler they know they can trust there's no certainty over what is running.

Ken Thompson pointed that one out. What a lot of people don't mention is the date at the top - he pointed that one out in 1984 .

I use venti, an archival storage system originally develloped for Plan 9 from Bell Labs and now available on a host of other systems via Plan 9 from User Space. Venti is strictly archival: it stores blocks permanently. This storage is organized into "arenas", or pools of a fixed size. When one arena fills up, it is sealed, never written to again, and the system starts dumping bits into the next one.

Primary storage for my venti system is a pair of mirrored SATA disks. Yes, magnetic disks can fail, but with mirroring they're still cheap enough to almost certainly be your first line of defense. When an arena fills up, I burn it to CD (by default, they're 512MB each) and mail that to a friend three time zones away. If my house burns down, I can recreate everything up through the last arena by basically dd'ing the contents of those CDs to a new disk.

Using a real archival system has other neat benefits, too. You don't have to worry about whether you saved the right version of something, or how to organize different versions over time; it's all automatic. I've used this for "work stuff" for a long time with very good results; after my last laptop hard drive crash, I've started using it for personal stuff (although I haven't made that quite as automatic yet). I can now "cat /n/dump/2008/0712/usr/a/src/cmd/ngcscatgen.c" to see the version of that file as I was working on it over the summer. Pretty nice.

I use venti, an archival storage system originally develloped for Plan 9 from Bell Labs and now available on a host of other systems via Plan 9 from User Space. Venti is strictly archival: it stores blocks permanently. This storage is organized into "arenas", or pools of a fixed size. When one arena fills up, it is sealed, never written to again, and the system starts dumping bits into the next one.

Primary storage for my venti system is a pair of mirrored SATA disks. Yes, magnetic disks can fail, but with mirroring they're still cheap enough to almost certainly be your first line of defense. When an arena fills up, I burn it to CD (by default, they're 512MB each) and mail that to a friend three time zones away. If my house burns down, I can recreate everything up through the last arena by basically dd'ing the contents of those CDs to a new disk.

Using a real archival system has other neat benefits, too. You don't have to worry about whether you saved the right version of something, or how to organize different versions over time; it's all automatic. I've used this for "work stuff" for a long time with very good results; after my last laptop hard drive crash, I've started using it for personal stuff (although I haven't made that quite as automatic yet). I can now "cat /n/dump/2008/0712/usr/a/src/cmd/ngcscatgen.c" to see the version of that file as I was working on it over the summer. Pretty nice.

http://cm.bell-labs.com/who/ken/trust.html

http://en.wikipedia.org/wiki/Thompson_hack#Reflections_on_Trusting_Trust

it is very hard to analyze the security of a system even with open source, but it at least becomes possible.

You have a point, but we could just as well throw our hand up in the air, we are fucked anyway.

And, of course, taking this to the extreme, you get "Reflections on Trusting Trust" by Ken Thompson: http://cm.bell-labs.com/who/ken/trust.html

http://cm.bell-labs.com/who/ken/trust.html

http://en.wikipedia.org/wiki/Thompson_hack#Reflections_on_Trusting_Trust

it is very hard to analyze the security of a system even with open source, but it at least becomes possible.

Someone linked to the trusting trust speech earlier, but here it is again:

http://cm.bell-labs.com/who/ken/trust.html

There are a thousand ways to change code without it being obvious that it is changed. Especially when you control the distribution of binaries. I'm not sure why China would bother with something as insidious as a gcc or g++ hack, but they could if they were intent on it. Also, they could just distribute modified libraries and not tell anyone they don't match the source. Granted, some people might slip through, but who really builds their entire OS from source repeatedly? I know, BSD and Gentoo, but we're talking about people who actually have work to do, and who obviously use a binary distro.

For anyone who is really concerned, the Chinese government can provide a compiler and they can build their own copy directly from source.

As long as I can compile it myself, I don't see the problem.

Off-topic but a good read:
http://cm.bell-labs.com/who/ken/trust.html

Even visible source code isn't entirely safe:
http://cm.bell-labs.com/who/ken/trust.html

Always a fun read.

In the apt words of Dennis Ritchie, "One of the comforting things about old memories is their tendency to take on a rosy glow."

According to one of the guys who was there on day zero, UNIX was *not* designed from day one to be a networked multi-user OS and security and separation of concerns were *not* there from the beginning.

http://cm.bell-labs.com/who/dmr/hist.html/ In the latter half of 1971 (nearly two years after UNIX's "day one"), "with no memory protection ... every test of a new program required care and boldness, because it could easily crash the system". Sounds like somebody describing Windows a decade ago, doesn't it?

Please stop parroting the fallacy that the reason UNIX is more secure is because it has always been secure. Security, networking ... these were later additions to UNIX too, the real difference is that the additions were better architected.

That's not good for either portability, long-term maintenance or, especially, security. Nasty things can be found in BLOBs, both there on purpose and by accident. What can't happen, though, is for these nasties to be fixed or removed. For that you need the source and no substitute will do.

Go read Ken's article again. The point is that even the source is not enough. Open source is necessary but not sufficient to truly understand what code will do.

Raven64, please stop trolling about the GPL and go back to where you came from.

If you bother to read the OpenSolaris FAQs, you'll find that there are two licensing shortcomings with OpenSolaris still. The first one, as you skirt around, is the granularity of the CDDL - it does not apply to whole packages. And that leads the to the real problem: OpenSolaris, as fantastic as it is in many other ways, it is partially closed-source binary.

That's not good for either portability, long-term maintenance or, especially, security. Nasty things can be found in BLOBs, both there on purpose and by accident. What can't happen, though, is for these nasties to be fixed or removed. For that you need the source and no substitute will do.

Then you'd have to hand compile the compiler, because you can't trust the binary compiler not to insert stuff.

Sorry to hear that but it does get better in uni. I'm a computer scientist from Victoria, in the early 90's I taught lab classes at RMIT and have been a commercial developer for 20 odd yrs. My own son did his VCE in the late 90's and I have to say the teacher was brilliant. Basically the course consisted of writing a database in Pascal which if done correctly (in stages that build on previous stages), is a great introduction to programing. The same teacher taught maths to my daughter, he introduced the concepts of algebra using excell which I also thought was a good use of technology for year 7-8(?)

However I realise everyone's milage will vary with the education system and some of the hoops you jump through are just societies "rubber stamp" or even your teacher being "human". If you find your course boring you have to be carefull you actually do know what they want you to know. I got bored and dropped out of high school in what is now called year 11 and it wasn't until I was thirty that I got a chance to go to uni again as a mature age student. No matter which way you look at it, failing because you haven't memorised the sequence of menu selections required to create a pie-graph isn't going to help you.

Once you are confident you know the course material and can pass the course with ease, read what interests you the most, if your interested in programming/science then personally I recommend three "classics", The Art of Programming", The C Programming Language", The Demon Haunted World.

Now get off my lawn!

Making that whole system *secure*, otoh, is almost impossible, especially when it is something as large and distributed as a national voting system. If a company could actually make a completely secure voting system, they could also have a good DRM system. (Yeah, I did say "good DRM system", which shows how possible I think that is)

From Ken Thompson's essay Reflections on Trusting Trust, he says it isn't enough to check the source code, you also have to check the compiler, the output from that compiler, and I would add, in the context of a voting system, everything that is or could be in the system/network.

I would like to respectfully disagree here. Your comment can be too easily be summarized to "well, if you can't solve every possible flaw, you don't have a secure system, and so there's no point in trying, if they're all insecure anyway, any system is as bad as any other."

This belief is flawed. Even if you can't prove that there isn't any possible attack, it is nevertheless true that there are better systems and worse systems, and you don't want a worse system. Being able to check the source code-- and, better, having the source code open for anybody to look at-- is in fact a very good start. Yes, it is possible that there may be some hithertofore-unknown flaw in the compiler, and some extremely ingenious cracker might be able to find it and find a way to use it to manipulate voting results... but this is a billion times less likely than the case of some open port left accessable, or a deliberately open back door, that would be found by careful inspection of the source.

(You've misquoted Ken Thompson's conclusion, by the way. His actual conclusion was that you should never trust any program you didn't write yourself. Apparently he's never seen the programs I've written myself.)

On a side note - how hard can this stuff be? It's not like they aren't making a fortune from these things - it's seeming like they are barely able to break even so they have to hire "below the barrel" talent...

Making a machine that counts or tallies votes shouldn't be very hard, and should be a first year programming assignment.

Making that whole system *secure*, otoh, is almost impossible, especially when it is something as large and distributed as a national voting system. If a company could actually make a completely secure voting system, they could also have a good DRM system. (Yeah, I did say "good DRM system", which shows how possible I think that is)

From Ken Thompson's essay Reflections on Trusting Trust, he says it isn't enough to check the source code, you also have to check the compiler, the output from that compiler, and I would add, in the context of a voting system, everything that is or could be in the system/network.

[...] or is there some other meaning of beta that I'm missing?

The one where its values will give rise to dom, obviously.

Ken Thompson talks about using untrusted compilers in his lecture, "Reflections on Trusting Trust".

(See also: this)

Open Source licencing is not necessary to build a system with high Nixon Number, nor is it assured that an OSS system will have one. However, I would argue that(barring substantial advances in static analysis of binaries, or the like) publicly auditable code,

Doesn't do you any good unless you can prove that the version running on the computer terminal at the polling station is the publicly audited version.

along with a publicly available trusted compiler,

A far greater mind than I has already discussed this and pointed out that with a sufficiently determined attacker, there's no such thing:

http://cm.bell-labs.com/who/ken/trust.html

publicly disclosed hashes of all binaries, etc, etc. is in practice necessary to achieve a Nixon Number high enough to be considered for critical uses like voting.

How do you verify that the system is using the code that matches your hash rather than just ignoring it and running its own version?

End of the day, the GP's right. No matter how open or closed the voting system used, it can't really be trusted unless it provides a separate human-verifiable vote for checking purposes with every single vote cast.

But Google is really playing with fire here by using more than one meaning for beta.

After all, values of beta will give rise to dom!

Sorry the links didn't work out: here's one: http://cm.bell-labs.com/7thEdMan/vol2/learn.bun