Slashdot Mirror

http://cm.bell-labs.com/plan9/

See? There have been innovations.

Your observation is underappreciated in too many circles. Though the EC also recognizes the need and called upon member states to get their act together, very little has actually happened on either side of the pond despite widely available, easy to use encryption technologies.

(Links and bold are added for emphasis)

on the existence of a global system for the interception of private and commercial communications (ECHELON interception system) (2001/2098(INI))
29. Urges the Commission and Member States to devise appropriate measures to promote, develop and manufacture European encryption technology and software and above all to support projects aimed at developing user-friendly open-source encryption software;
. 30. Calls on the Commission and Member States to promote software projects whose source text is made public (open-source software), as this is the only way of guaranteeing that no backdoors are built into programmes;
. 31. Calls on the Commission to lay down a standard for the level of security of e-mail software packages, placing those packages whose source code has not been made public in the "least reliable" category;
. 32. Calls on the European institutions and the public administrations of the Member States systematically to encrypt e-mails, so that ultimately encryption becomes the norm;

Further, what's kind of funny is that though businesses make all kinds of noise and bluster about security, many go ahead and put business plans and meeting minutes on servers which (not counting holes and back doors) explicitly sign over access to their competitor(s). However, see if M$ makes it easy for businesses to see what their so-called tech support is agreeing to.

They have no way of knowing that the source the can review actually matches any binaries provided via Windows Update.

This is one of the standard points in any meaningful security guidelines.

Brief summary: You don't run any binaries from anyone else. If you don't have the source, you don't run the software. You have people that can study and analyze the source. And you compile it all yourself. With a compiler from a different vendor.

Then there's Ken Thompson's famous (in some circles) Reflections on Trusting Trust article, which is required reading for anyone with serious security interests. It gives you some ideas about how to deal with the compiler itself. Actually, it mainly gives you some good questions, which you might want to try answering, just for the experience of dealing with an infinite regress of trust.

Most of Microsoft's customers will simply use the binary code. In an organization that does this, there's no point whatsoever in discussing the possibility of a backdoor. The management has already demonstrated that they don't care, because their security is only for show.

(Note that this isn't Microsoft bashing. The same applies to any system, including one that's open source. If you run a binary from an outside source, you have no idea what's in it, and you have to meaningful security. People have on several occasions managed to sneak backdoors into releases of linux and other open-source systems. Granted, they might have been caught quickly and fixed, but this tells you nothing about that binary that you're downloading right now.)

DOCSIS 3.0 is just an interim solution that allows copper networks to survive a little bit longer. Fiber is currently estimated to have a maximum bandwidth ceiling of 150Tbps http://cm.bell-labs.com/who/nuzman/papers/nuz_wid_infocom06.pdf the true potential of fiber optics has yet to be realized. Cable companies are investing in better compression algorithms and modulation methods to better utilize their existing network and do not want to foot the bill to build an FTTP network although they could. Most FTTP systems like FIOS are running on BPON (622Mbps down 155Mbps up / 32 customers between the customer and the central office) and they are currently testing GPON networks which provide (2.488Gbps down to customer and 1.244Gbps from customer to internet / 32 customers ( CO to home))the fiber itself does not have to be changed out only the connecting equipment in the central office and at the customer's home. These estimates are based off of technology available today. Think about the future and what will be available then. Remember that compression is used only to reduce the bandwidth required to something that naturally has large bandwidth requirements. Less Compression = Higher quality. Why do you think cable technologies like HDMI have no compression? With the popularity of internet vidoes, web applications and the like increasing what technology do you believe is more prepared for the future?

Countering "Trusting Trust":

"It's interesting: the "trusting trust" attack has actually gotten easier over time, because compilers have gotten increasingly complex, giving attackers more places to hide their attacks."
January 23, 2006

http://www.schneier.com/blog/archives/2006/01/countering_trus.html

Ref.

Reflections on Trusting Trust:

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

Truly, ALL your base is belonging, not just a little.
[firmware]

Well, no I haven't. At first I thought you were talking about Robert Morris the Financier, and I thought, "What the hell does he have to do with cryptography? Did he encrypt some secret data into the Declaration of Independence or something?"

Your Robert Morris, I must admit, is a little more exciting.

If they want some usefull stuff they might as well get them from Plan 9. The "successor of Unix." It has been open source since 2000 AFAIK.

Individual voters can log into a website and ensure that their vote was recorded correctly (and yes, this is done in such a way that nobody can prove to another party which way they voted).

If I can log into a website after the fact and display who I voted for, my boss can stand over my shoulder while I do so to make sure I voted the way he wants me to. Your voting DRM is just as vulnerable to the analog hole as music or videos.

Anyone can get a list of the people who actually voted, so they can check that nobody voted twice and that every voter was valid.

And you can't do that with paper? Why?

Each of the candidates can independently and programatically verify that the tallying was done correctly (again, without exposing any one specific ballot).

This would be a nice feature, granted. But I'm skeptical that this would provide more than a false sense of security. Would the system be secure against attacks such as this?

How can an operating system be considered "secure" if it has proprietary software installed? It can't. Proprietary software security is unverifiable by anyone you can trust and therefore unworthy of being considered secure. [...] The cure is simple: install nothing but free software on your computer. Give yourself the freedom to inspect, change, and share the software, hire someone else to do it for you, or leverage the talent of a community of hackers improving free software all the time. This is not about making everyone a programmer, it's about giving people the freedom to control their computers while building a society of cooperation and social solidarity. Proprietary software denies you your software freedom, so deny proprietary software a place on your computer.

Wrong. See Reflections on Trusting Trust. Most people just download the binaries of FOSS, because compiling yourself is pretty inconvenient. How do you know that the binary was produced from that source? Even if you download the source and compile it yourself, how do you know there wasn't a backdoor hidden in your compiler? Let's say you wrote your own compiler. Well, you either had to compile that compiler you wrote (in which case you're exactly in the same situation as before), or you had to run the your code through an interpreter, which may be a software VM style interpreter, or at the very least, if you wrote the code in machine code, had to be interpreted by the CPU. How do you know there isn't a backdoor hidden in the interpreter? You'd have to either write your own interpreter in software (which either has to be compiled or interpreted, which brings you back to the same problem), or you'd have to build your own hardware-interpreters (aka your own CPUs) from components.

In other words, you're trading security for convenience. Maybe there exists some people who care enough about security that they'd build their own CPUs from scratch. Most people don't have the skills or are too lazy. Maybe of those people, some care enough about security to write their own interpreter/compiler software. But most of them are too lazy or don't have the skills. Of that latter subset, maybe some of them care enough about security that they'll actually read the source code. But most of that subset is too lazy or don't have the skills. Of this even smaller subset, maybe some of them care enough about security that they'll have a policy of only using FOSS, and depend on the community to verify the source code for them. Others will be too inconvenienced to do even that. Of those, maybe some will be willing to use a mix of open and proprietary software, balancing convenience versus security. And yet again, there exist people too lazy to do that, and who just use whatever software came with their computer.

Cheers...

The really significant part of the story, is that in order for a tech journalist to remain publicly relevant, they have to at least appear to know, understand and 'like' Linux.

Consider the enormous change that has been achieved in terms of acceptability and mind share. Linux is now recognized as being the future universal operating system, to not recognize and acknowledge that, leaves a tech journalist marginalized and redundant in the tech communities public eye.

So regardless of whether or not he is sincere, he is at least accepting and acknowledging the truth of Linux as THE operating system of the twenty first century ;).

In some ways, this is disappointing. Don't get me wrong: I love Linux (see my sig). I use it for everything. But I don't think it's right for everyone. I don't think anyone should be forced to use it, and I don't think you should have to know, understand or like Linux to be a tech journalist. If people like Linux for anything, it should be on it's own merits, not what market share it has, or because it's required for the job.

Should you know Linux if you are writing about it or something related to it? That goes without saying. But if you are, say, developing an operating system orthogonal to Linux you shouldn't have to be an expert in Linux. Or if you are writing for Mac world, you probably don't need to know what Linux is.

I hope Linux never turns into the next Windows, and not just in the sense that the UI is similar. I don't ever want to hear the phrase "nobody was ever fired for going with Linux". As a matter of fact, I don't ever want to hear any variation of "nobody was ever fired for buying IBM"; I want to hear that phrase replaced with a sincere "we evaluated all our options and chose Linux for it's superior stability, security, technology and low TCO".

This is a rather ignorant and VERY Microsoft-centric world-view... Use any other operating system, and you can start playing the video while it's being transferred.

Huh? Windows Media player starts playing most media file types as they download. It's been like that for years, at least as far back as I can remember Windows Media Player existing (Win 98?). I just verified it with an mpeg demo file at this link.

This sounds strangely like Plan9

http://plan9.bell-labs.com/plan9/

Those mechanisms are for RPC, you can choose whatever method you like when your whole IP stack is SSL encrypted, like mine.

I'm constantly surprised at what people will plod along with!

even Linux ! say it aint so.

Eventually your malware will overwrite your snapshots or the binary that restores them.

That said, the OS I use has daily snapshots (or as often as you like) to a central server (thus enabling coalescing of data blocks i.e. repeated blocks of data are stored only once). The choice of which snapshot to use is per process, so, for instance, you can compile yesterday's code in one window and last weeks in another and see what changed. Or boot any terminal into last month's state of any other etc. etc.

"If the channel is noisy it is not in general possible to reconstruct the original message or the transmitted signal with certainty by any operation on the received signal E. There are, however, ways of transmitting the information which are optimal in combating noise.... It is possible to send information at the rate C (the channel's capacity) through the channel with as small a frequency of errors or equivocation as desired by proper encoding."

For audio, the channel capacity of cheap cables are many orders of magnitude greater than the information rate of an audio signal. That allows for a great deal of redundancy and a negligible (but not necessarily zero) error rate.

yo i just read this,
http://cm.bell-labs.com/who/ken/trust.html

the best bit.
"In college, before video games, we would amuse ourselves by posing programming exercises."

i think he is one to something here...

Of course, this basic problem was described quite eloquently by Ken Thompson. He went after the compiler, but the problem of proving that the binary you have matches the source you have is a tricky one no matter what.

There actually are some very clever solutions to try to catch cheating compilers like this, but none of them are trivial. It's a cat and mouse game, and there are actually proofs that winning either side completely is impossible.

Link

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

Everything is a fs. Get used to it.
It's the future, and it's not going away ;-)

http://cm.bell-labs.com/plan9/

You can scream all you like, happy or not.
Lunix is insecure be design.
Root is a design fault.
That's why it got removed in the next version.

It appears that the manual for Unix "First Edition" (1971) makes no mention of the password being encrypted in /etc/passwd, so it may have been stored in plaintext at that time.

However, the manual for 7th edition Unix (1979) specifically states that /etc/passwd contains the encrypted passwords. So, Unix had been encrypting passwords on disk for at least 12 years before Linux existed. The GP appears to be making things up.

Refs:
http://www.cs.bell-labs.com/who/dmr/
http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf

It appears that the manual for Unix "First Edition" (1971) makes no mention of the password being encrypted in /etc/passwd, so it may have been stored in plaintext at that time.

However, the manual for 7th edition Unix (1979) specifically states that /etc/passwd contains the encrypted passwords. So, Unix had been encrypting passwords on disk for at least 12 years before Linux existed. The GP appears to be making things up.

Refs:
http://www.cs.bell-labs.com/who/dmr/
http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf

Of course, that's physical entropy, and I don't know that it's the same as "information entropy."

Your problem is that you need to kill the BOFH. You will need a silver stake, electrical gloves, KCN pills, a SCBA, 20 oz of deionized water blessed by a geek, and The New Testament. Don't enter at night, and don't expect to catch the BOFH by surprise. They don't sleep, they lurk. If you can sabotage the coffee and soda machines you can drive them out of their lair. Otherwise you may have to defeat their army of PFYs. Good luck! And if they capture you and decide to Megger your balls, use the cyanide pills.

First you assume that the person(s) that read it would catch anything evil in it. It's not like the evil code is necessairily going to be in a function called doEvil(), it could be very cleverly hidden among legit functions so that most people would miss it. With good obfuscation it wouldn't be hard to make something that people would have to play with a debugger just to figure out what is going on, and as such miss it on anything less than a really intense code audit.

This sort of "evil" is very transparent. You can code a hidden buffer overflow/exploit/backdoor in such a way that it's not obvious (= instead of == for example, caught in the Linux kernel once). But how do you hide an access to say, /proc/interrupts? You need to spell out the filename, and there's got to be an open or fopen for it somewhere. Any attempt to encode the filename is going to be weird and suspicious. Plus, file parsing would be quite a bit than a single line of code, so it's hard not to notice something is being read, stored, etc.

Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone. The people who read the code have to be honest for this to work.

Uh huh. Such a thing would be an outright admission of evildoing. Depending on what is being done it might be enough for a lawsuit, and definitely enough for mass publication all over the web to ruin the developer's name. Slashdot had a story on some Mac developer who claimed there was an anti-piracy check that'd delete the user's documents folder. Just the claim (which the developer says wasn't real and intended to scare people off) resulted in such outrage he's probably unemployable for years now.

No, anybody with any brains would deny any wrongdoing and claim a hacked server, or pretend that no mail is arriving at all.

Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries. That the checksums differed wouldn't be of any note, since it could just be that different compile options were used, or even a different compiler (for example using ICC since it generates more efficient binary code). As such no source audit would ever turn up the problems.

But 99% of Linux software is delivered by the distribution, with the package maintainer often being completely unrelated to the developer. While it's not impossible for something weird to be going on, those distribution maintainers do things like patching the source and dealing with its bugs. You can bet that eg, the Debian maintainer of Firefox looked at the source.

Finally, even if you compile your own, you assume that nothing else is in on it. I'll refer you to the classic Ken Thompson story http://cm.bell-labs.com/who/ken/trust.html. Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.

That's a tricky one, but you can use a different compiler. Compile gcc with icc for instance. For OSS I think this approach is unlikely due to the frequence with which somebody decides "let's rewrite this part". It's easy to make a compiler that hiddenly changes some well known part of the source, but it's much harder to deal with a complete reorganization of it. To keep it up would need updates

First you assume that the person(s) that read it would catch anything evil in it. It's not like the evil code is necessairily going to be in a function called doEvil(), it could be very cleverly hidden among legit functions so that most people would miss it. With good obfuscation it wouldn't be hard to make something that people would have to play with a debugger just to figure out what is going on, and as such miss it on anything less than a really intense code audit.

Second, you assume the people who look at it aren't in on it. So maybe a couple people look at the code and find the evil bits. They contact the developer and ask what's up. The developer then lets them in to his cabal, who can use the evil bits for their own ends. The people decide they like this and don't tell anyone. The people who read the code have to be honest for this to work.

Third you assume that anyone other than the developer even bothers to look at the code. Not always a valid assumption, just because the code if you there doesn't mean anyone gives a shit. Maybe it is too complicated, maybe they just don't care, regardless the code being open is no guarantee that someone looked.

Fourth, you assume that the binaries are the same as the source. I'm betting at least some of the time, and probably more often than that, you install things from a binary package. It's easy and much faster than compiling everything. Great, but how do you know the source follows the binaries? It would be easy to release an untainted source, and then tainted binaries. That the checksums differed wouldn't be of any note, since it could just be that different compile options were used, or even a different compiler (for example using ICC since it generates more efficient binary code). As such no source audit would ever turn up the problems.

Finally, even if you compile your own, you assume that nothing else is in on it. I'll refer you to the classic Ken Thompson story http://cm.bell-labs.com/who/ken/trust.html. Some other program, and not just the compiler, could be in on inserting a trojan. It might never exist in source form, yet always get compiled in. Thus even a build from a verified source isn't a defense.

Really, what it comes down to is open source may give you a warm, fuzzy feeling but it isn't actually proof everything is on the level. Really, you have to test what the software actually does when it is run. You can't say "Well the source is open so it can't do anything evil," because you just don't know that. It's far more useful to analyze how the program acts on a system, than to look over the code.

After all, if looking at the code revealed everything, OSS would never have any bugs. You'd look at the code, see all the bugs, they'd all get fixed. Yet it does, nasty ones. My favourite is the BIND flaw discovered back around 2000 that was in essentially every version of BIND ever. Despite the fact that many people had looked at the code, nobody had ever noticed this. There was no ill intent, no conspiracy, it just wasn't something people saw.

As such the same could be done for something evil. Hide it well enough in the code, and nobody will notice it.

In the ten years that [Dennis Ritchie and I] have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character.

What do you mean? Plan 9 is alive and well.

The successor to Unix got rid of root altogether from the OS.

I prefer a boast like "Nothing to escalate" than "Secure by default"

Why install vista, when your girlfriend's name is Glenda?

I wonder how many Slashdotters recognized the significance of a girl named Glenda running Plan 9...

For those who don't get it, see http://plan9.bell-labs.com/plan9/glenda.html

I think Plan 9's Venti probably does what you want. There is a version which runs on Linux; see Plan 9 From Userspace for details.

If you used a proper OS with incremental backup, you'd have the peace of mind that files never die.

This article was a fairly interesting journey into Shannon's world of Information Theory but, in my opinion, it is little more than an exercise in applying that kind of idea to user input devices on small electronics.

I understand the enumeration and recognize that it scales quite quickly per key. The reason I don't think this has been employed or will be employed is that people are not willing to take the time climb a learning curve--even if it would take them a few weeks of memorization and the time saved over their life will be huge. If that were the case, we'd all just use one button and our handhelds would interpret Morse code (see summary). The implementation discussed here is probably even more confusing than Morse code.

On my current phone, I have 9 buttons that I push and depress to cycle through different sections of the alphabet. How is this any different? It's four less buttons and a hell of a lot more memorizing, if you ask me.

You don't need a VM for such security. Plan 9 has a preaty neat solution for this problem. It is simple and actually solves many more problems at the same time. Per PID filesystems. If you come to the mailing list or #plan9 I am sure someone would be grateful to explain how it works and it solves more than this problem.

-- Ron

Root is a design fault.

That's why the inventors of Unix took it back out again when they did their next OS

btw. it's dependent

The problem is that MySQL has the lion's share of the market, despite being (relatively speaking) crap.

It is only crap if you assume some very detached notions of what features a database engine should support (like full transactions, enforced foreign keys etc.) Those features are strongly promoted by the academia, which is why all fresh grads cannot understand why everyone uses MySQL and hardly anyone PostgreSQL. They also make for great buzz words, and as we all know nobody ever got fired for choosing Oracle. However, where it matters, it turns out that the actual needs of real life applications are different. Google uses MySQL and so does Yahoo. Most services at Google use a storage system called Bigtable, which has been developed completely in-house. And, surprise, it is not a relational database. As you can read in the paper I linked to, initially there was a plan to support general-purpose transactions in Bigtable, but after carefully inspecting the real applications' needs they decided against it.

It's a lot like windows in that respect: if you want to ensure that a machine you sell can run random software for grannies, you (sadly) generally put windows on it.

This analogy is dead wrong. Oracle is like Windows. Government agencies and big non-technical corporations use Oracle. MySQL is like Linux. PostgreSQL is like... umm let's say like Plan 9 from Bell Labs.

People should fix the bug --- that some software doesn't have a database abstraction layer --- and then choose that best DB.

Most a database abstraction layer can give you is familiar API across all databases. It won't give you the ability to switch database engines, because they are very incompatible. Perl has DBI which doesn't make Perl applications any less tied to specific DBMSes.

Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

APE -- The ANSI/POSIX Environment
http://plan9.bell-labs.com/sys/doc/ape.html

Plan9 has the Abaco web browser, it's still in development but you can use Gmail with it apparently.

http://plan9.bell-labs.com/sources/contrib/fgb/aba co.pdf

So put your 2c back in your pocket.