Slashdot Mirror
Indian Military Organization To Develop Its Own OS
An anonymous reader writes "Several newspapers have reported that DRDO (the defence R&D organization of the Indian military) is planning to create an OS. The need for this arose due to the cyber security concerns facing India and that all [conventional] operating systems are made outside India. About 50 professionals in Bangalore and New Delhi are expected to start work on this operating system." At least one of the linked articles says the new OS, though home-grown, would run Windows software.
WINE doesn't stand for "Wine is not a complete, Windows-compatible operating system sans the security vulnerabilities".
I can't wait for the poor bastards to try outsourcing development to India.
I hope the DRDO does better than their previous projects. For example, the Arjun tank has not been a good use of Indian taxpayer money, but internal politics seem to keep it and similar projects alive: http://en.wikipedia.org/wiki/Arjun_MBT
The Wheel: It's tired of getting reinvented.
A buddy of mine just revealed some news to me. He's been reliable about this shit in the past and he's in a position to know, so I trust it but YMMV.
Backstory: Microsoft eats their own cooking ("dogfood") except in cases of epic failure. Like Hotmail running on NT. Or Visual Safe Source for Windows's RCS. They use a heavily modified version of perforce and a hierarchy of repositories. Yeah, it's a mess and there are a number of technical as well as human/social problems.
Well, multiple groups within Microsoft have had enough and switched to git for day-to-day work (using a gateway to push their changes to an upstream p4 repo). They're trying hard to drop 4 entirely and go with git. From what I know of their development practices, they really need something like git (Linus, himself, agrees). But who's going to tell Balmer that they're switching to software written by arch-enemy Linus Torvaldes? You might think they'd prefer that (we're using your free software, faggots!), but chances are VSS 2011 will contain some sort of half-assed distributed RCS support.
"I am become /dev/null, the destroyer of data."
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
I know this is obvious, but come on...
Seriously, why not take a *BSD or Linux OS release and do a full source code review on it? It will take a lot less effort than creating anything from scratch, plus they can submit bug reports and code fixes back to the corresponding opensource projects. (Everybody wins!!!) Any mature OS would not be plagued by bugs that commonly occur in large new code bases. After reviewing and approving the OS, they can simply track changes of future releases in order to maintain trust.
Don't use Binary Blobs, I agree, absolutely, if you care at all about your Sovereignty. Get the source tree for an already very well secured OS like, say, OpenBSD, or perhaps Linux (though OBSD is, I believe, generally developed with practices that encourage better security - less focus on feature, more on audits and exploit finding/fixing). Have your 'trusted' developers from your nation go over every line of code, to make sure no trojans/backdoors/intentional exploits were added, then build it all yourself.
Of course, there is still always the possibility you have a hacked C compiler. Man, I can't remember the name of it now, but sometime in, I think it was the 80's, someone made a pretty famous presentation/paper about putting a self-perpetuating trojan into a compiler. You could give the compiler source code, and the binary of the compiler to the 'mark', but you could completely remove the exploit from the source code, as long as the exploit was coded to compile itself into subsequent builds of the compiler; that is, the binary was infected, but the source was not, but it didn't matter since the infected binary could build a copy of itself into the next build of the compiler. The exploit could then additionally do something like whenever it built other binaries or libraries, add some exploit code to them as well.
I suppose you need your own people to do a dis-assembly of the compiler to verify that. Or, build your own assembler in machine language, then build your own compiler with your assembler. Once you've done that, if you have a trusted compiler, and verified source code, you don't really lose security by using Open Source. If anything, it'll *probably* be more secure, if it's popular enough to have a lot of devs analyzing it and fixing problems.
Simple reason: "Everybody wins" is not an option in real wars.
Only if they write it in Haskell.
Of course, there is still always the possibility you have a hacked C compiler. Man, I can't remember the name of it now, but sometime in, I think it was the 80's, someone made a pretty famous presentation/paper about putting a self-perpetuating trojan into a compiler. You could give the compiler source code, and the binary of the compiler to the 'mark', but you could completely remove the exploit from the source code, as long as the exploit was coded to compile itself into subsequent builds of the compiler; that is, the binary was infected, but the source was not, but it didn't matter since the infected binary could build a copy of itself into the next build of the compiler. The exploit could then additionally do something like whenever it built other binaries or libraries, add some exploit code to them as well.
That would be Ken Thompson.
It was Ken Thompson, the man himself, that you're referring to. The talk in question can be found here: http://cm.bell-labs.com/who/ken/trust.html
What the fuck? A government checking the code it runs on computers with sensitive data is "national socialist"? You think the United States government doesn't do this on CIA and DOD computers? Or are you a nut against building roads?
We're talking about doing this only for government computers used for sensitive government data.
You're talking about the trusting trust attack, which was made famous by Ken Thompson.
Thankfully, you can counter the "trusting trust" attack using a technique called "Diverse Double-Compiling" (DDC). See the linked PhD dissertation for details.
- David A. Wheeler (see my Secure Programming HOWTO)
I find it amusing that some people think that a nation's defense research organisation, which helps build ICBMs, supersonic aircraft, tactical software and so on, needs advice from someone who reading slashdot on how to write an operating system.
Well, in the US -- I don't know about the Indian military -- the same defense establishment that operates those ICBMs etc. also mostly runs Windows. Which is a pretty clear indication that they do need help, and the Slashdot crowd would probably be a good place to get it.
This is at least partly personal experience talking. When I was a medic in the USAF, one of my secondary duties was "computer systems security NCO" for the ER where I worked. Which mainly meant light sysadmin duties, trying to keep machines patched and virus-free with absolutely zero support from the actual hospital IT staff, and debunking "I LOVE YOU virus" warnings and similar bouts of hysteria that Col. So-and-so forwarded to everyone's e-mail ("it must be true, the Colonel said it!") Actual security was a joke.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
It seems to me that an OS developed by an org that's never made an OS before, by 50 people, that isn't examined by many people around the world in many different contexts and from many different approaches, is going to be less tested and less secure than other OS'es. Not to mention the lack of applications, and the burden of creating all the applications from scratch, and a developer community for them, and again the smallness and isolation of that community and its apps leaving security to a very few very busy people.
If I were responsible for protecting India's IT infrastructure, I might start an Indian state project to create an OS. But I'd just start with Android or Linux, and assign the people I have to investigating its open code for security holes and starting applications needed by essential Indian users. A lot less work, a lot more global partners to use (and many to omit from trust without losing everyone). Leveraging the English speaking skills of educated Indians to partner with people around the world to secure India.
Reading the press, it seems they're really talking about a component in their new line of spy and military satellites. They mention they've got orders from other countries. So probably this venture is not at all calculated on security rissk, but rather on a perceived market opportunity. In which case it is even more likely to totally fail, but not after wasting a lot of time and money better spent on actual Indian security risks.
Probably some general's nephew thinks he can sell some Linux clone to the government, and so the rest of the state and media apparatus starts talking it up.
--
make install -not war
Comment removed based on user account deletion
While this is a valid point, it really doesn't take into account the fact it takes a long time to develop a mature, reliable, secure OS. OpenBSD has been at it for more than a decade and still has issues, and some of the finest minds in security work on that, and they started with a relatively secure code base to begin with.
If you're writing your own OS from scratch, you can expect 20-30 years before it will be more secure and reliable than existing OS's (and those OS's won't be staying still so they will mature in that timeframe as well). And that's if you have experts working on it. If you're going to copy an existing OS, then what's the point?
Now, I can understand that a country wants to encourage OS development, and is willing to sponsor a defense project to build an OS, with the expectation it may take 20-30 years.. but it should really stay hidden and not publicised like this, otherwise the people start wondering "Hey, why don't we have this OS yet?" and then you end up pushing it into production long before it's ready.
The sad part is, India has a huge problem with brain drain. A large percentage of the top computer scientists relocate to EU countries, or the US. Only the truly patriotic or mediocre or worse candidates stay home, or perhaps those with some kind of community ties...
However, if India became seriouis about building a world class research program, it might encourage top talent to stay in India. I can see that as another benefit of such a program.
So i guess my point is, there are a lot of reasons why this is a good idea, but sadly.. I doubt that those reasons are the reasons they're doing it.
If you need web hosting, you could do worse than here
Obviously, they're not going to develop any such thing. Ever. This is one of the most brilliant job security moves I've ever seen in the computer industry. Kudos!
Yes I have met some amazing Indian developers out there. There are also many H1B visa programmers who may be lacking in experience and are desperate to succeed in a foreign country which, lets be honest, considers them outsiders. They make half the pay in many situations and can be fired and sent home in the span of a week for any petty job disagreement.
True innovation requires the ability to make mistakes, learn from them, and try something new - which is contrary and alien to the H1B "cog developer" system. I doubt many Americans could be as disciplined and work under such pressures and situations.
Back home, India is building a truly amazing scientific pool of talent. Expect to see major challenges to American engineering & science - the population numbers game almost guarantees 3x the genius-level talent waiting to be discovered and educated.
I said no... but I missed and it came out yes.
Here's how some outsourcing places work, and it's an old model used from the Rocket program under Stalin to US and Indian businesses:
At the start you have the experts and they have people that need training but they pretend to be experts. After having contact with your experts for a while they vanish to work on higher priority projects and you are suddenly in contact with a new lot of people that really need training. In the end you are milked dry with nothing to show for it other than what is obviously some first attempts in whatever environment you have. Your project doesn't matter, the technology transfer and your cash are what the outsourcing company is aiming for. It's very similar to the long running project German rocket scientists were put on in the USSR that never got anywhere but trained a lot of staff for the real rocket program.
The trouble with Windows [compatible] OSes is not that it should be capable of running software written for Windows. It is that Windows itself has design weaknesses for various reasons not the least of which are related to its DOS based origins and support for old, misbehaving "legacy" software. To write a Windows compatible OS, you would also have to mimic a wide range of idiosyncratic behaviors in order to support Windows applications.
Now, if for some reason, all the bad-behaving software were cast aside and only good Windows software were used, the notion might stand a chance. I remain quite skeptical it, or any Windows-compatible OS, would become completely viable.
Looking at it another way, the SaMBa project is constantly playing catch-up against the moving target that is Windows networking. And that is just one aspect of the Windows OS family. Imagine this on an entire OS? It would be hard pressed to actually work.
They'd be better off making a BSD modified OS and pulling in WINE.
As someone who knows a bit about the origins of NT, with regard to Windows NT, you are full that substance that leads to substantial growth in the business...
...". Eventually OS2LDR.exe got renamed, but it remained the same through at least the first release (I left Micrografx before the next release of Windows NT came out). In the end, Windows NT was more secure than it was when it started, but it was not "secure".
Windows NT first several beta's booted using the OS2LDR.EXE file from prerelease versions of OS/2 2.0. The first thing you saw on the console was "OS2LDR.EXE
Windows NT was not designed for security -- The first version was hacked together using bits of OS/2 2.0 code, ports of existing Windows code, etc. For the record, I worked at Micrografx when they (a) had source code and early binaries of Windows NT, and (b) was part of the team that worked on OS/2.
With regard to your spurious example implying ACLs make something secure, again, you've been shoveling out the stables. ACLs do not make something secure (they may contribute to a security solution) and the lack of ACLs does not make something insecure. Security is not about how you achieve something, security is about what is achieved. Fundamentally, the only truly secure computer is one that not connected to a network, kept behind several locked doors, with guards that are so well paid or loyal such that they cannot be bribed. This goes on and on, no software added after security is certified, no external access other than keyboard, no externally accessible disk drives/cdrom/usb, etc. Everything else is a careful balancing act of risk, vulnerabilities, and mitigation.
At least one of the linked articles says the new OS, though home-grown, would run Windows software.
Brilliant. If you're into security, there's one rule of thumb you can always count on. Don't develop your own. Invariably you'll overlook something obscure and subtle and will create a weakness big enough to fly a 747 through. Stick with time-proven methods that have been under the microscope for years and have withstood the test of time and had all the bugs, shortfalls, and subtle problems worked out of them. Basically, you're not smarter than all the people that have contributed to making the currently available selections as secure as they presently are.
If they're going to create an entirely new os themselves, in-house, for the sake of security, they're about to re-learn the above lesson.
And sorry, but runs Windows? The whole security problem there to begin with is its never-ending craving to run old software that just wasn't bothered to be written securely. Look at the giant headache that was the breaking of windows software when XP came out. Then when Vista came out. Then when 7 came out. This is going to be a whole new level worse. They may say it can run Windows software, but either it won't run MOST of it, or they're just going to be defeating one of the primary purposes of writing their own secure OS to jimmy it to run any sizeable portion. If they're insisting on making their own OS, they may as well expect to have to write their own software too. In for a penny, in for a pound.
I work for the Department of Redundancy Department.