Slashdot Mirror
Security Through Obsolescence
dlur writes "This article and this article (both variations of the same article written by roblimo) delve past security through obscurity, into using old, out of date software to secure a site. Maybe it's not always in your best interest to snag the latest kernel? Perhaps think twice before jumping at the chance to buy MS's latest OS."
No one can break into my house because I have a moat and a drawbridge, and a dragon behind the door. Old, but effective.
Ask Slashdot: Where bad ideas meet poor googling skills.
This is simply a variation on security through obscurity. Make sure the operating system and software it runs are so old that current hacking tools won't work on it. Sure, that will stop a bunch of script kiddies. It's just like running MacOS will make you immune to most viruses.
Without the script kiddies, you still have to worry about serious crack attempts. By using antique software, it is probably relatively easy to do some research and find security vulnerabilities.
"... like AIX that has never been widely used for Net-attached servers but is adequate for handing out simple Web pages .."
Um, I don't know about you but last time I checked, AIX is far more capable than most UN*Xs out there at just about everything.
By no means is it "old" or "outdated."
At least with current software when a hole is found it will get patched - more quickly for some companies than others. What happens when a major flaw is found with older OSes/apps? Do you really think MS will bother to write a patch for win95 or Apple for mac os 7.1? You will not only have a security problem, but to fix it you'll have to upgrade or migrate to a new platform.
I still wouldn't rely on this for really critical security implementations.
;^)
The main problem is that most vendors stop supporting old products. This creates a huge security threat. Just because no one knows about security holes don't mean they exist.
Sure you've eliminated probably 99% of all script kiddie threats and if that's the only threat you can identify then by all means this is a cute idea. However, as security administrator at my company I do my best to secure against any and all threats which means I must presume that old versions of Solaris (for example) have gaping security holes that were never fixed and therefore running the leatest and greatest with all applied security patches and a rock hard configuration is my best bet when it comes to security.
Roblimo's friend does have a point, though regarding Macs. Old Mac's are really the most secure systems out there. Simply because they can't really do much. They weren't designed to be networked and so there aren't any services to exploit
--
Garett
It's Security through time.
They've got the argument all wrong - it's not more secure because it's obscure - it's more secure because older software has been around longer, and the kiddies have already found the obvious bugs and they've been patched.
Would you run a 2.5 kernel on a computer where you worried about security? I'd hope not.
Time to move my mp3 collection over to a gopher server :)
--
Don't sweat the petty things, and don't pet the sweaty things.
Now I can dust off that old VAX in my livingroom and figure out how to load CP/M on it for my eStore!
Eve Fairbanks says I drive a hybrid!LOL
I'm serving web pages from by NeXT Station at home. My logs show tons of attempts to reach internal WIN-NT paths. Which is slightly amusing. But in the end, that's just my DMZ machine, and my linxis(sp?) firewall is trusted to keep out other naughty people. Still, nothing keeps the wife from opening an email with an executable attachment... So my web server stays up while I refresh the image on my PC. The most stable running box in the house is still the NeXT.
Above comment is personal opinion. Poster is not a spokesperson.
A few years ago, I remember researching firewall products and stumbled across one that ran on MS-DOS. According to the marketing hype, MS-DOS was the OS of choice because it was impossible for a hacker to do anything remotely with an OS that had no remote accessiblity. They had custom ethernet drivers for a small number of cards, and a homegrown GUI (definitely not Windoze). IMHO, it wasn't the best product (for a variety of reasons), but I'll bet it was every bit as intrusion-resistant as advertised.
Per yesterday's /. article on the current state of Air Traffic Control systems, is sounds like this is standard fare for them as well. They've certified that the ATC systems that STARS is replacing are hack-proof, simply because the systems are so old that few people in the IT world today were even alive when they were introduced.
Of course, a system like this is still subject to physical abuse, and an old system that is broken into pieces is just as bad as a new system that is the subject of a DoS....
Rule #1 -- Politics always trumps technology.
I had a nice Webserver running thttpd on an iPaq, but then some script kiddie linked to it on the slashdot front page. I just can't win.
We ship DOS based and Windows based medical data collection software out of our shop, and we've had WAY fewer problems (one, to be exact, compared with over a dozen) with people hacking into our DOS stuff vs our Windows stuff, despite the fact that we have 50 times more DOS units in the field than Windows.
Not to mention that the laptops we ship the DOS software on gets stolen a lot less frequently, since our DOS software will run on 286s...
Denver Isuzu Suzuki
It's called appletalk and while PC users were being strangled with novell netware Apple had this easy-peasy way to connect macs (ring style) with some $30 adapters (under $10 if you homebrewed!)
You can run appletalk on ip.
In the future, I would want to not be isolated from my friends in the Space Station.
Hey, nobody ever managed to crack my A/UX server before I switched to OpenBSD -- maybe there's something to this.
Of course, the flip side would be that the whole OS is toast as soon as a vulnerability is found. Hell, Apple won't admit they even _made_ A/UX any more.
--saint
(Seriously. Try to find it on their site. You'll find Newton stuff first.)
That's right, buy the source to the end of life products you use.
I understand that this is an expensive proposition, however this is what we do where I work.
This way any bugs/exploits can still be researched and fixed by the good guys, and the bad guys are just shooting in the dark.
Not that we intended to have all of our COTS (Commercial Off The Shelf) to go end of life, but you make do!
However when UK air traffic goes down for a few hours and the only developer who knows the product is in hawaii for two weeks on his honeymoon (yep. That was me.) you have a problem!
In the future, I would want to not be isolated from my friends in the Space Station.
This article seems to suggest that older operating systems are better because hackers tend to shoot for the lastest and greatest, and find weaknesses in them instead.
So what happens if there are alot of webservers, etc out there who run obsolete software for this very reason? Hackers don't exploit a particular OS, webserver, etc just because it's new, they also do it because that particular flavor is popular as well.
Even if the software is old by today's standards, rest assured, as long as it's running on alot of servers and PCs, it'll still get attacked.
On another note, I agree with the aspect that when a particular OS/software is out in the "wild" for a long time, it gets scoured for weaknesses and gets patched accordingly. Eventually the OS/software becomes robust and secure over time. In the end it's no so much that it's new, but that its strong and secure. And that's what matters the most.
A Penny for my thoughts? Here's my two cents. I got ripped off!
Hi, I know you're Unisys now, but do you still have any mothballed UNIVACs around? I have a secure project that I need one for.
A UNIVAC I? Mmmmmm, mercury delay line storage, 500 microsecond memory speed, and 5,600 tubes. What more could I ask for!
Is this the real reason the green screeners at work claim the AS/400 is so secure? And all along I thought is was because there were only, I don't know, maybe 2 on the internet not behind massive firewalls!
hmm,
-Pete
Soccer Goal Plans
This article just goes to show that good security is hard, and is often an afterthought.
Lasers Controlled Games!
When I read the original article at newsforge, they served up an ad encouraging me to "Move to Apache 2.0" because "The More You Wait, The More You Lose". screenshot
Just try and load your root-kit onto this machine. Whaddya mean ?OUT OF MEMORY AT LINE 10.
Previously discussed on slashdot back here
Now I can dust off that old VAX in my livingroom and figure out how to load CP/M on it for my eStore!
No, man, throw it in your kitchen and make it a VaxBar.
The speed of time is one second per second.
I used to work at a small Unix workstation company in the 80's, Callan Data Systems. All our accounting and payroll software was running on an old Callan machine that was running CP/M. That made it much more secure from internal attacks than a Unix machine would have been...all of us systems programmers knew holes and tricks in Unix that would get us root on any Unix machine inside of 15 minutes (mid 80's Unix was not all that secure). Sit us down at a CP/M machine, however, and most of us would be completely lost, and would wonder off to go back to playing with Unix.
Now we securely sit in the dark.
This is the flip side of saying non disclosure is more secure than disclosure. Obsolete means nobody knows about it whether anyone gives a shit about it or not is a different question.If we had all sorts of PDP-11's around here or Link analog computers I'm sure that eventually someone would break them just because they're there.
this is a pretty flawed argument. Do these security experts actually look at "script kiddie" tools? If they cared to do a little homework they would see that many exploits and tools cover a wide array of software versions. Exploits for antique software are relatively easy to find. Now you could claim that _obscure_ software is more difficult to crack, and you would probably be right. But keep in mind that that software is obscure for a reason--it's probably junk. Just because you are running last generation's software does not mean the current cracker generation can not get to those exploits (or information needed for the software).
I believe there is a little bit of confusion in this article between obscurity in the sense of software not being widely used and obscurity in the sense of proprietary closed-source software. There is also the confusion of software _differences_, which the author of this article bungles together with software age. In any case, this article is seriously misguided. Let me explain:
There is an Object. It could be your physical hardware, your OS, or simply a version of a software package. Imagine two generic Objects, Object-A and Object-B, exact in every practical way. Now imagine an Exploit that works on Object-A (and a cracker has access to this object). It also works on Object-B (your object) because they are identical. Now imagine there is an Object-C. It is very similar to Object-A and B, but has a few slight differences. Now the Exploit will need to change to accomodate this. This is _security_. This is the same principle viruses (biological or computer) work on. The differences between objects makes them secure. The less difference, the less secure. Think of any *ix security measure. Passwords, for instance, are simply ~8 character differences (and a login name) between one *ix and the next. Attempting to break a password by trial-and-error is impractical. Crackers rely on this principle of _similarity_ of systems to break passwords. They download a system's password file and use a "word file" to crack passwords. This word file is merely commonly used passwords--again, the principle of similarity. Most *ix systems have a password file in a common format and there are common passwords. Common system properties (/etc/passwd, etc.) + common user psychology turns what is a very secure method (passwords) into a very insecure method. One small admin. change could make the difference between a system being cracked or not (such as moving daemons to a "strange" location or partition, etc.).
Software age has nothing to do with security. The article really has many seperate issues tied together and it really is not a good idea to just use older software for security sake.
Dijkstra Considered Dead
No one can steal my data!
I have no network. My backups are stored on 5 1/4" floppies.
Not only can no one read these things, they'd need a truck convoy to haul them away. No way in hell they're sneaking past security with a motherfucking semi truck!
You see? You see? Your stupid minds! Stupid! Stupid!
From the article: ' You never read about this kind of "security through obscurity," which can just as correctly be called "security through obsolescence." Despite this lack of publicity, it may be as effective a tactic as any other, and it can be implemented without spending a dime. '
... which raises an interesting point: If you are spending time to do this, aren't you investing -- perhaps even wasting -- a lot of it hoping that your machine is beyond reach or unknown? Is that amount of effort really worth nothing? If someone succeeds in breaking the barrier, all that conscious thinking will have gone to waste, as the end result is still 'I have a cracked machine'. With current software, you have some recourse. It may always be true that the need for endless-upgrades will persist. I don't think this sounds like an alternative.
Most people will know this, but I have to quote Jamie Zawinski: But as we all know, Linux is only free if your time has no value, and I find that my time is better spent doing things other than the endless moving-target-upgrade dance...
I could be wrong, but the knowledge and practical experience needed to try something like this looks to be of little worth to the people who'd want to do it.
========================================
Death will come, and will have your eyes
-- Pavese
This is a good example of security through obscurity, particularly the MacOS example in the article. Obscurity is no basis for a security model, but a little obscurity thrown in on top of some real security can't hurt.
For example, a tech I know runs a MySQL server that shouldn't be exposed to the outside world. It's behind a firewall and the port is blocked, fine. It's also run on a non-standard port. Why? Because if somebody cracks the main network, they still have some work to do to get to find the MySQL server. That's time to discover the intrusion and fix the leak.
Summary: Security through obscurity: bad. Security + obscurity: good.
If it makes you feel any better, I agree with you. That's a concern I have about OpenSource as well. On the flip side, though, the biggest security problems that MS has is caused by their over-abundance of 'features'. The reason that the Melissa virus went around the web was not a flaw in the system, but an oversight into how it could be used. MS included .VBS capability to allow Windows automation, but hadn't considered that linking it to Outlook could result in a malicious attack.
It seems to me that having the source code of an OS or a product might reveal potential exploits, but the most damaging attacks we've seen so far seem to be from exploitation of features designed by a company trying to be more enticing. I can understand the negativity towards your concern, however I do not condone it.
You are right in that the more you know about a program deep down, the more capable you are of damaging it.
"Derp de derp."
I'd bet you wouldn't be able to hack my C64 without doing a whole lot of research. And since most crackers don't even do their homework (they just runa script), chances are only the most dedicated would get in.
T Money
World Domination with a plastic spoon since 1984
Security through obsolescence may be a bit of a misnomer. When I take an older OS release and apply all of the relevant patches, I know that the patch OS is considerably more mature that a newer version. Espicially a new major release with a newer or different components which have not been extensibly tested.
This is not to say that OS and software companies do not try to thoroughly test their software. They do. But even in the largest, most sophisticated test lab, one cannot recreate all of the possible conditions that will be revealed when the software is released into the real world.
The reasons older (obsolete) software may be more secure are really two fold. Older software, due to creaping featurism which haunts all software development activities adds features, which adds chances for security holes and errors. I assert the increased features, and espicially increased interfaces (user, programmatic and otherwise) increases the likelyness of security issues. The second issue with older (obsolete) software is that it is more mature. Please understand this carefully- older software that has been patched ot the current patch level will be more secure than software that has not been patched.
I think equating obsolete software with security is quite a stretch. I do agree with the thought that mature software will have fewer security issues. Added to this the fewer interfaces on older software gives it a greater chance to be free from security issues.
-tpg.
I'll give you a counter-example, and this is more to the point.
Mac OS 8.6 was *THE* standard before 9 and X. More stable, better for the environment, better for the economy, etc. etc.
There was a free upgrade available everywhere to get you from 8.5 to 8.6. Yet two years ago I ran 8.5 for a year and a half.
Why? DIDN'T need to upgrade. It gave me everything I needed, didn't crash out* (I had 1 or 2 problems with ProTools, but it was an anomaly) , and I didn't need USB support.
My system was set up in such a way that everything, CDEV's, INIT's, and all extensions got along with each other and the only time I had to reboot was when I wanted to turn my computer off.
To extend this, if you have a set up that has had the HECK tested out of it, stands up to "attack" (whether that means a "hack" for an network box, or a heavy load for a server) and doesn't give you problems, why re-invent the wheel?
In the future, I would want to not be isolated from my friends in the Space Station.
What it does not stop is those who live off hand-me-downs. My experience with a pentium 200 is that it's not much fun browsing the web with it.
The rule of affordance states that locks are meant to be picked.
OS/2 - because choice is a terrible thing to waste.
This is a good example of security through obscurity
There is no such thing as a "good" example of security through obscurity.
The biggest problem with security through obscurity is not that it doesn't provide security (although this is one of the problems), but that it provides a false sense of security.
if somebody cracks the main network, they still have some work to do to get to find the MySQL server. That's time to discover the intrusion and fix the leak.
This is a perfect example of the problem with it.
Your friend probably thinks that the "non-standard port" thing is pretty clever, and that it gives him time - he thinks that he's done something to secure his network, when in reality he hasn't; the system is just as vulnerable as it was before he moved the port, but he believes that it's more secure. This is hubris at it's worst.
Incidentally, using old software is not necessarily obscurity - in general, older software has fewer features, fewer lines of code, so therefore fewer potential bugs.. fewer bugs means fewer potential security problems.
We run Netware.
The most secure cryptosystems in the world are "open source". The encryption key is kept secret, but the method of encrypting the key is published. People are encouraged to whack at it. If a system gets broken, someone gets famous, but people know quickly.
This seems like a much better model for OS development than "let's hope no one remembers that old trick".
=brian
I think security thorigh diversity is a much better propostion. It is well known that biological systems become vulnerable if they are too homogeneous. For example, if one species dominates an ecosystem then diseases will spread more rapidly and affect more of the population. The same argument can be applied to computer systems. If one hardware and software configuration is dominant eg MS, then vulnerabilities will affect a larger number of systems and viruses will spread more rapidly.
How would you know when your OS has been modified (without your approval), replaced (without your approval) or worse yet modified in a way which you were not informed.
Run an intrusion detection program from a physically remote computer. Such a program compares a snapshot of the system (stored on the remote computer) to the current system. A reinstallation will be detected and reported. In order to defeat this system, the intruder needs to physically compromise two machines at once. You can even set up intrusion detection from several remote mahines to guarantee that physical access isn't a risk. Problem solved.
Frankly, I don't see how your "source modification and reinstallation" attack is a risk specific to open source systems. There are utilities that can accomplish the sort of things you're talking about without modification of source code, and if an attacker has physical access to a machine, they'll be able to get in regardless of what OS you're running.
Yes. I am aware of "tripwire". And, there may be similar programs. And, all systems running an open source OS run this program each and every day, do they? I think the problem is that the problem is not solved unless you actually solve it with every installation. If you are doing that, great. And, other means may be employed to make certain the code running on the system has not been altered.
I think the point here is that management must be aware of the risks. And, the risks are the same with the OS code as they are with custom applications. Except that everyone has the generally available source code for the OS but not your key custom apps.
It is specific to open source simply because the source is what is changed. It provides the mechanism.
The mistake is to falsely assume that risks are identical when they clearly are not. Physical access does not equate the risk between having the source code and not having it. That is no more true that telling a support person they do not need the source code to fix a bug since you gave them unrestricted access to the hardware.
The code is essential to fix bugs in key custom applications. And, the code makes it much easier to modify the OS. Any hacker knows that for a fact.
Yes, open and closed systems can both be attacked. But, the risks are not the same. The methods are not the same. And, the management that must be imployed also must take the differences into account.
As I suggested above, one way is to customize the OS and put the source code for that custom version in your vault.
In other words, take an open source OS, modify it and add the value of obscurity (for what it is worth) by controlling access to the code that was used to build the OS you run.
It is not one or the other as many like to paint it. You can have both. Take the base distro that benefits from open source, customize it enough to make it "different" in key ways and then place your source into a secured system thereby gaining from the obscurity you placed on your version.
That is one thing you can do with open source that you can not do with binaries. Oh sure, you can do some things with just the binaries. But, that is no fun, not easy and has significant limits.
Many who prefer open source do so because of how they can customize it. And, that is a primary benefit for many installations. The point being made here is that the process can enhance security as well. And, part of that enhancement is the obscurity you can place on your version.
I think people have to forget this idea that security can not be enhanced via obscurity. Clearly it can. But, that does not suggest that closed source systems are more or less secure at all.
What do you do with the source code for your key custom applications? Do you publish them? If your stuff is written under the GPL and you do distribute them, then perhaps you have to. But, if you do not distribute them, I doubt anyone publishes the code just "because". At least not if those are for key custom applications. People are not going to walk in off the street and advise you your code has a bug in it.
There is a difference between distributing something under the GPL and gaining the benefits because of doing that; and not publishing the source code for key applications. And, in my book an OS running on my key systems is a key "application".
So, the equation is between the source of your custom apps and the source of your OS not between open and closed source for operating systems. There is a big difference between open and closed source for an OS.
NexuSys - Linux support by the best
Replacing logons, installing key loggers, etc, is not difficult to do on any open or closed source OS I am familiar with (various commercial unixes and MS NT family) given you have physical or administrator access to the machine.
How do you know when your closed source OS has been modified/replaces/etc without your approval?
HTH.
XML causes global warming.
I'm sorry Lewis, but I'm having a very difficult time trying to understand you. When you say "There is a big difference between open and closed source for an OS.", do you mean that one is significantly more secure than the other? If so, why?
My interpretation of your original argument is as follows: since code is available for open source operating systems, hackers can modify this code and install the modified code in systems they've accessed (physically or remotely) to gain information about the system and network. This is a classic trojan attack, and it's been implemented against a wide array of operating systems, closed and open source. Closed source utilities are typically modified via standard reverse engineering techniques. It is more tricky to modify a utility that you don't have the source to, but not significantly more tricky. Remember, modifications to an open source utility have to keep that utility working and compatible, which can be a nontrivial engineering problem. Plus, there are plenty of ready-to-install trojans out there for all sorts of operating systems. A good sysadmin will guard against trojan attacks by running an intrusion detector.
Also, are you arguing that open source has an advantage because a sysadmin deploying an open OS can gain some obscurity advantage by altering the system code and recompiling? This might be possible, but it would be stupid. The slight advantage gained in having a slightly different OS would be overweighed by the loss of the support of developers on the main code branch. Bugs that you introduce in modifying the OS don't get fixed, and fixes for existing bugs are no longer compatible with your modified OS.
I would argue that from a security point of view, the main difference in open and closed source comes from the development process. Many eyes, shallow bugs, and all that.
Why not put it into the compiler/assembler suite? Add random jumps everywhere to foil buffer overflows. Might bloat your code and increase the run time linearly, but it would bring obscurity to a whole new level. You still have to recompile everything, but then that in itself might do the trick. On second thought try compiling on an obscure compiler. That might fool the buffer overflow demons at address #oxDEADBEEF.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
Especially considering active development has ceased on source trees that have been superceded and that modern applications are sometimes much more secure than their predecessors.
Oh, and occasionally development occurs only because of a serious exploit that requires immediate attention. Let's install BIND 8.0, hoping that the script kiddies will not observe this blatant error, oblivious to the fact that experienced (cr|h)ackers would perceive exploiting such an application or operating system a trivial activity.
This concept is nothing more than an esoteric form of "security by obscurity." It disappoints me that the Slashdot editors would begin to advertise such a blatantly rhetorical and poor security practice.
Do you like German cars?
Are you really naive enough to think you can argue against buffer overflows in a piece of software you have never seen?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
All the "obscurity" does is extend the time before the FIRST person discovers a hole. Once one person finds a hole and that info hits the Internet, it's not obscure any more. What, you think all the script kiddies personally research and discover security holes?
It's a similar problem to that faced by music companies trying to copy-protect CDs -- all it takes is for ONE person to rip the protected CD, then it's out there.
-----
PGP Key ID 0xCB8FF658
If the security of the system is then pendant upon whether or not the OS (or the application in question) is open or closed source, this distinction becomes irrelevant. Consider that the required ability to access the system to compromise said components cannot be any less difficult either way. At this point, anything is possible. While you might believe a closed source component is more difficult to compromise, amazing things can be done with disassemblers and knowledge of APIs (I've had to do it myself). Furthermore, the mere fact that it is closed source makes it even more enticing to hack, in the sense that there would be less reason to suspect something is wrong! The false sense of security it lends makes it a more valuable target, and thus spend time analyzing.
Think about it another way, does the open or closed source nature of software affect in any way the distribution or propogation of viruses?
Black holes are where the Matrix raised SIGFPE
Security and Convenience are bitter, mortal foes. Using long forgotten and ancient software may be secure(dare I suggest also abandoning ASCII and replacing it with a hieroglyphics-based standard) but it's not really convenient(or practical). Forgive me, but I don't see businesses rushing to downgrade their software. Issues of support, maintainance, licensing, etc. really make this one a tough sell. Security and Convenience just don't get along well...
What's in a Sig?
Well, actually, about Linux 2.2, Debian Potato uses 2.2.19 (what I'm running), and Debian Potato is still maintained (for now... soon to be outdated), and has a *very* good security record.
...and this lie crawls out of its mouth: 'I, the state, am the people.'
Back when the Atari 8-bits were out, there was a race between companies that would copy-protect their disks (through bad sectors, etc.), and companies that would produce drives that would copy them. IIRC, after this had gone on for a while, someone produced an almost uncopyable disk. Turns out it was using an old copy protection format not built into the last couple generations of copying drives.
Seems like a lot of people here need a refresher course on why security through obscurity is bad. It's not bad because it relies on the attacker not knowing something--most security relies on that. It's bad because the thing that it relies on the attacker not knowing is poorly defined.
Take the common example of the "secret URL". Noone could possibly guess the secret URL to my admin page, right? Maybe, but it's a moot point, since they don't have to. Your browser doesn't know the URL is supposed to be secret, and neither does your webserver. It can leak out via literally dozens of paths. I find "secret" pages virtually every time I take a look at my webserver referrer logs.
use constant PERL_IS_BROKEN => $] >= 5.006;
Well, as a general rule, I dont install MS software until the third service pack comes out. This is due to the multitude of problems that come with MS new releases. As for security, why haven't the web and OS programmers set up a VM for browsers and email with no access to the underlying OS? A separate VM for each logon, and the user just kills his own VM ..........
actually, I had my Mac Plus "owned" by nVIR B, an Olde Skool (krusty) virus...
But that's part of the equation. When it happens you recover and you learn something new. Periodically running a virus catcher can help! Then it never happened again.
Now your comments on the security of vanilla distro linux are actually On topic and a great spring board. Like you said with the old macs, you "get your setup just right"...
It's the same way with linux. If yr not running behind a firewall (even a lame one like a linksys) you should NOT connect your linny to the net! There are at least 5,000 web pages on how to harden your linux distro, not to mention security BOOKS you can buy (don't run send mail! disable all the basic accounts! don't run finger!)
The beauty of linux is that if you want to you can see the software you are running and you can change it. Now so far the only changes I've done to software is to edit some header files just to get it to compile!
No one runs with a new linux distro (well, actually I still am, but I'm behind a firewall, and that machines dual boots into MacOS more often). The idea behind most distro's is to give you almost everything you might want and allow you to prune away.
Now you have a custom set up. If something goes wrong now you know whats on your machine, trace it back. And if you find it's becuase of a code exploit you cna either fix it or find the update.
As a side note: Maybe the distro for newbies would be more like a minix- a minimal set of unix stuff to get started.
And you just add capabilities as you go.
In the future, I would want to not be isolated from my friends in the Space Station.
Let me put it like this: compare system security to optimzing a program. Fixing the open access problem is likely to give you the most return for your time. The difference between open and closed source OSes is comparable to spending all your time for a fraction of a percent in improvement. Furthermore, if the one big optimization is done, it renders the smaller optimization inconsequential.
HTH
XML causes global warming.
remove all the chrome badges & remove the manual from the glove box & throw it away.
IE, remove all indicators of what OS it is, from inside the OS.
The only compartmented multi-level secure operating system I have first hand knowledge of (HP-UX CMW) is delivered to the customer with complete source code. Again, access is more important than openness of source. The NSA is working on a secure linux version that will have world-open source. Trust me, they have a better handle on the fundamentals of security than you do.
The applications my company develops can include source code, if appropriate. Our customers know the importance of physical security. If they give people unsupervised physical access to their systems they cannot and do not try to blame us. Similarly, they maintian control over source in such a way that black-hatters can't compromise their systems in this way.
Your perception of security obviously differs greatly from mine - the customers I work with have security requirements that likely exceed anything you are familiar with. Open source produects and operating systems fit without problem in these environments with no adverse security implications.
As far as your questions:
What do you mean? Everyone in our company (that is, everyone with physical access to our machines), has access to the source code for our custom applications. The custom applications we deliver to customers may or may not have source code with them, depening on the desires and requirements of the customer.
Yes.
Obviously. If you don't control who can modify your systems, you have no security.
This is the crux. When we use an open OS, we still control how that OS gets installed on our systems. We know where it came from, who had access (if any) to the source between acceptance from trusted sources and installation on our systems. We have means to verify the integrity both of source code and resulting binaries. Without that control, you have nothing.
Yet you maintain the openness of the application (OS in particular) in detrimental to the security of the system. Yet here, you agree it's not about opennes but about control. We agree. Our systems running open operating systems are controlled no less vigorously than our systems with closed source.
Source is irrelavent. You think sourceless OS/application suites protects you in some fundamental way. They don't. Others have pointed this out. Though you maintain the difficulty of hacking with a sourceless system, the real world shows that the majority of security exploits occur in closed systems. How do you reconcile this fact with your claims?.
We treat both classes of software the same. Physical access is controlled. Installation and modiification of software is controlled. Audit logging and detection systems are employed. It matters not who has access to the software from which the software is derived. That access is irrelavent as long as we properly control our systems.
Not the organizations I work with. So you let anyone who feels like it install shrink wrapped software on your systems? You think this is secure? If not, what is the basis for you claim?
As I said before, it's a matter of intellectual property rather than security. Just because source code is widely available does not mean exploits using that source code are easy to inert into either trusted sources of that source code or the particular systems I manage that are based on similar (though separate) copies of that software. Do you think someone with the source can magically propogate his hacks into trusted distributions, vendor systems, and even installed systems? If he has that capability, again, the openness is the *very* *least* of your problems.
You ignore the forest for the trees. You would ignore the greatest threats to your security in your claims that the openness of source code is a relavent factor. If your security policy is broken, using closed source products will not help you.
I'm obviously not going to convince you of anything. The real world shows that open applications and OSes can be very secure. Closed systems can also be secure. Or both can be very insecure. It doesn't help your case that the most dominant closed source OS for the last 10+ years has a long historry of extreme security problems. You can not ignore the real world. Your claims, if believed, would only lead people to chose that particular closed source solution over more secure open solutions. How does this promote security? What, exactly, is your motivation?
HTH
XML causes global warming.