I doubt you would reverse engineer anything for which you had the source code.
The difference is not whether you are assigned to fix a bug or you are a hacker attempting to take over a system.
The difference is only the means you have at your disposal. There is also a difference between an inside versus an outside attack.
If you are on the outside then having the source may or may not do you any good. If you are inside, then it makes it easy. And, that is why you have to understand the difference between having the source code or not.
I do not suggest you can not do similar things without the source code.
But, no developer I know of thinks that not having the source code is just as easily.
If that were true, you could just delete all those files for your custom apps and just edit the binaries once you get version 1 to boot up.
No one does that right? I mean absolutely no one. So, everyone agrees that modifing source code is the easiest way to make changes. That does not change just because it is an OS.
There is a big difference between open and closed source for your OS because of the security issues raised. (Forget about trying to prove the overall security is more or less because of that factor. I am well aware of the fact that an open sourced development process may very well result in more secure code. But, I am focused upon the specific security issues that an administrator needs to account for.)
The security issues related to the OS are similar to those related to applications. Is there a difference in the security issues for a shrinkwrapped application and a custom application written in-house? I do not think any administrator would think they are the same. If you have access to the source code for a key application in your business, you need to know how you treat security differently. You may do nothing about a shrink wrapped application. But, you should provide access controls for those applications for which you maintain the source code. And, you do that despite the fact that the public does not even have access to it. For your OS, the public also has it. So, how does that change your security efforts?
You also have to make a distinction between outside and inside attacks. As far as outside attacks go, once the OS is complied and installed you get what you get. If you want to argue that an OS developed in the open will result in superior code, I can agree with that. It is most likely true. But, that does not mean that open source does not create specific security risks that need to be addressed.
And, yes, many attacks can be engaged without the source code. But, no developer I know of claims that having the source does not make alterations easier. It clearly does. (Again, for the outside attack it may not matter if reading the code does not disclose a problem.) But, for the inside attack, having the source code opens up a whole range a easily implemented attacks.
And, the observation here is that once you begin to change the source code for the OS (or any application for that matter), you enter into a new level of administrative responsibilities. Now, any organization that does in-house development knows how to deal with those issues. The point being that with open source systems, those issues also relate to the OS itself.
The idea that a typical distro could be modified by a company, the changes kept secret and the modified version installed on all systems is just an example of what could be done. And, you do not have to alter any particular utility or function. You could just customize the log-on process with a custom version that would not be easily duplicated without having access to your code. Make your code private or secret (lock it away). And, then install the custom version. Besides there are any number of reasons why you might want to customize the version that employees boot up everyday anyway. The point here is simply that even with an open source OS you can benefit from a measure of additional security through customization and obscurity of what was done. And, perhaps in the process a simple way to allow any normal user to be given a warning is their "system" runs differently some day.
If you just install the standard RedHat distro but someone else makes their custom version and installs it on top of yours, you may or may not be aware of the change. The point being that you can customize the OS in such a way to put normal users on notice if things change. In other words, you can do things that help normal users serve as a "tripwire" as well.
The whole point here is that the security issues related to open source versus closed source are not identical at all. And, you have to understand how they differ.
I have no doubts what so ever that many can do wonderous things without source code.
But, it is also true that everytime anyone is assigned to correct a bug, fix a problem or alter the way a system works; the first thing they ask for is the "source code".
So, no matter what you do the source code makes it easier.
Now, that does not mean that a hacker out on the internet is going to benefit from having the source code to the OS you are running. That is an external attack. And, such an attack may or may not be made easier simply because of source code availability.
However, administrators have to also be concerned about "inside" attacks. Attacks coming from disgruntled employees or simply from those who might abuse the trust they have been granted.
And, that is where the difference between having access to the source code and not having that access makes a difference.
And, again I compare the security issues with those associated with custom in-house developed applications. What do you do with that source code? Is it controlled in any way? Do you post it on the company bulletin board? Do you publish it? If open source does not raise additional issues simply because of its availability, there would be no reason not to publish all your code, right?
So, while you can do wonderous things without the code, that does not mean that particular security considerations need to be taken into account when source code is available.
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.
But, I doubt anyone ever thinks that it is just as easy to alter a program with or without the source code.
Funny that all developers I know of demand that they be given source code to anything they are responsible for fixing. It is just a whole lot easier to do your work.
So, it is false to equate open and closed source when talking about security issues. The issues are not the same. They are very different.
Having exclusive access to the hardware (even overnight) does not equate them either. Those who might want to change the program always want to start with access to the code. It does not matter if it is the OS or a custom application. If they have to fix it, they want access to the code that compiles the program. If they want to hack it, they want access to the code that compiles the program. They are the same.
So does it matter if the source is open or closed? Well, to the kind person who wants to alter it, yes it does matter a great deal. Where you need to equate the security issues is between the source code for your custom applications and the source code for your OS. (Assuming you have both.)
And, yes I do assume physical access to the equipment.
But, the point was that security must be different simply because the source to the OS is open. Those with access are able to engage in a different selection of ways in which the systems can be attacked.
It is not a matter of whether open source is more less secure than closed source. Rather it is that the range of security issues are different. It is just like the range of security issues related to custom applications written in-house where many may have access to the code and shrink wrapped applications where access to the code does not exist.
The possibilities are a different set. And, the use or lack of the use of obscurity can change that set.
And, the "sets" do not become the same just because of the physical access either. They remain separate and distinct sets. Some events may very well appear in both. Some events or threats may only appear in one or the other. That was the point of making a comparision to the source code of key custom applications. There is a reason why banks do not publish the source code for all their key applications. And, it is not simply that they are proprietary. They may be. But, other reasons apply also.
Do not confuse this discussion with any effort to convince anyone that open source OSs are more or less secure than closed ones. Rather this discussion deals strictly with the issue that security is different when source code is open. And, if you draw that out a bit, the set of concerns can be changed by altering the code, compliling it, put it into use and removing the open code. Making it obscure, in other words, and gaining the value of the obscurity you placed on it. Not to be confused with the obscurity put into place by a vendor only selling binary copies.
But, your spouse does not need to shoot you to get your spare cash. All your spouse needs is "access".
And, the point I was making is that not all attacks come from the outside. Real security can not assume that.
Banks do not assume that only bank robbers will try to get their hands on the loot. They all know that employees are to be watched like a hawk. That is why they have to balance their cash drawers every day. It is not because the bank is afraid they are short or longing customers.
Oh, I agree that "features" can often come with some serious security problems. No doubt developers do not have the innovative mind necessary to foreclose possible abuses.
But, the issue I raised did not relate to exploits because the source was open. Rather they relate to the fact that almost anyone can have it.
If you run RedHat 7.3, the source for your OS is publicly available to all. Is that the same situation you find yourself in if you are a bank and are focused upon the ATM software you run? No. I do not think so. Your ATM software is not publicly available via download. Your OS might be.
So, the wise are aware of that and take that fact into account. Many do not. Many think that because many eyes look at the code before it is distributed that controlling access to the code used to generate your OS is not important. And, that depends upon who the other guy is. And, what he can do if he has the source for your system and the access to replace your OS. Having the source code means you can change anything you want. And, so can "he" or "she".
The source code for your OS needs to be guarded in the same way that source code for any key application needs to be guarded. And, that is more difficult to do if everyone has a copy of it.
Your sysadmin may be correct in not passing around the root password. However, the root password is not required in order to modify the OS (assuming your have the source somewhere laying around), install your bogus copy and begin collecting those "passwords" for as long as no one figures out the OS has been replaced.
Just remember, if the jerk getting his way with your system can alter the logon, the new code can make a note of any passwords entered and just "grandfather" you in. So, it may be a while before it is detected that bad passwords work just as well as the real ones. Most people I know can type their own password without mis-spellings quite easily. And, even if you think you may have hit the wrong key, when "your're in", your're in.
So, it really depends. 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.
When I talk about insiders engaged in serious attacks, I do not exclude the possibility that anyone with the root password may be involved. Disgrunted employees and SYSAdmins are not mutually exclusive, now are they?
Just who is the "boss" over your systems? The first answer is the last guy who installed the OS?
The risk is the same for a key application (that handles your money) and a key OS. Except all OSs are key.
A few months ago I posted a number a few articles on my own web site about the security risk created by open source. No doubt a few/.ers recall finding out about the so-called attack upon open source and pried open their emailer.
Problem was that it was not an attack upon open source at all but rather a rather strong suggestion that having the source code for an application or OS can have its downside. And, that is that anyone who has access to that code and your machine can modify it as they see fit. And, those modifications may not be with "your" approval (assuming you own the joint).
The point was that having source code comes with a price. And, that price is additional vigilance and perhaps some controls.
It is known that a sizable threat comes from within and not only over the internet or lan. And, those who are in a position to alter your OS or key application also have the ability to abuse that access.
As was pointed out above, if you have your own home grown or modified OS, it may be more secure against outside attack simply because of its obscurity. And, yes, obscurity can be security. Of course, once the cat is out of the bag, you are in trouble because of your insecure system, if that is the case. So, security by obscurity is only as good as the obscurity lasts.
Of course, the solution to the possible risk of someone else planting a Trojan in your OS could be modifying it yourself (making it obscure in key ways) and then hiding the source code. In other words, closing the source as far as your installation is concerned.
That does not reduce your security to that of a well known closed source OS but rather takes the better security offered by an open system, modifies the system to change its character and then sealing it against the world.
And, since it is easy to customize a log on sequence or process and then obscure the code, your custom changes would not only be more difficult to alter by a third party but any change they make may be easily detected by normal use.
Of course, the parade of/.ers failed to see the concept or consider how it could help them.
Or, indeed make an open source OS even more secure than when they got it. That would give you the benefit of the multitude of eyes upon the problem and the benefit of obscurity as well.
But, no I have not changed my opinion at all. Open sources does create certain security problems that need to be understood. And, perhaps even taken advantage of.
Funny how every time some one decides against a Microsoft product it is deemed as limiting choice rather than making a choice.
A government (or any customer) is fully within their right to discriminate against a vendor for what ever reason they may wish. And, that includes defective products, inferior products, insecure products, proprietary products or simply the use of illegal means to preclude competitors.
The US government should take the same approach as indicated by Germany, France and Peru.
If you are going to be spending the people's money it should be for products not simply padding a single corporation's wallet.
I have email from individuals suggesting that I should not discriminate against Microsoft just because they are violating Federal Law.
But, that is a perfectly legitimate reason for doing so.
Actually, the use of linux has received its start from the bottom up. But, the numbers are hard to come by.
Many professionals in IT have started using linux on their home and personal systems for many reasons. And, when they find (found) that open source systems work just fine and can contribute, those technologies have worked their way into corporate systems.
But, the major bump will first come when the top companies in the industry openly support a linux/unix solution across all systems including the desktop.
It is stupid to sell Microsoft desktops and linux/unix servers when Microsoft designs its technology to harm those customers who try to benefit from non-Microsoft technology.
IBM, Hpaq, DELL, SUN, Gateway and others have to wise up and avoid the companies that design its products to interfere with the effective use of the technologies out there. And, that is precisely what Microsoft is doing. So, Microsoft is the company to avoid.
It is a good question whether IBM is going to support linux desktops under this deal.
I have often commented that linux on the desktop will have fully arrived when companies such as IBM, Hpaq, DELL, Gateway, SUN and others fully support the linux desktop as part of the full solution.
SUN (surprisingly) may be the first major company to do so openly. DELL tried and Gates illegal acts caused them to stop. Hpaq and others may make a deal here and there for linux systems. But, only when the companies actively promote the linux/unix (desktop/server) combination will the linux desktop really take off.
The technology is there. SUN's StarOffice is right there. Other office suites are also available. (Maybe, Corel will even reverse course and again offer WordPerfect Office on linux?)
And, with Lindows and Xandros both about to bring out their distros focused upon the desktop use of a PC (rather than a server), perhaps a few of those OEMs will seriously consider a promotional campaign.
The corporate accounts will come first. With Java and Delphi/Kylix as well as other development environments making cross platform applications feasible, corporate accounts can easily adopt a linux desktop or linux/Microsoft solution.
What is very clear is that Microsoft will design its products to harm those customers who try to use non-Microsoft products. That policy is dead obvious. And, it is directed at preventing non-Microsoft products from having fair and open markets. That is why Gates took the baseball bat to DELL. Microsoft's policy is to harm those customers who use other technology.
So, the quicker customers move off of Microsoft the better off they will be.
Microsoft and its spokespersons are so pathetic because they never use the truth or logic to propound or support their statements.
Microsoft is a typical pathetic liar. A pathetic liar is one who only judges what they themselves say based upon how good it feels when they hear themselves talk.
For Microsoft, anything that sounds like it may promote Microsoft's interest is classified as being true and correct without any evaluation of whether or not the statement is actually true or false.
The same applies to "right" versus "wrong" as far as morals and violations of laws are concerned. There is no independent determination of whether something is legal or not. It is helps (or appears to help) Microsoft, then it is presumed to be legal and therefore implemented.
That is why Bill Gates beat up on DELL to stop their promotion of desktop linux systems. That is why all of their illegal acts where approved at the highest level. There was no moral judgment.
That is why Bill Gates and Microsoft make the dumbest statements.
Under oath Allchin claimed that somehow the GPL was in part responsible for not including a SUN compliant JVM with XP. Never mind that SUN does not even use the GPL for Java. The importance to Allchin in making the claim was to bad mouth SUN and the GPL under oath even when the statement does not make any sense at all.
Under oath Gates and two other witnesses claimed that temporarily removing a few icons is what was bothering the court of appeals when they found that commingled code violated the antitrust laws. I guess the idiots at Microsoft do not know the difference between an icon and source code? Clearly their lawyers must since they tried to ask the court of appeals to take a second guess at the commingling issue. They said, "no", we meant what we said. So, Microsoft lies about the decision and fabricates a fake remedy claiming it is responsive while any one knows the benefit of the illegal commingling is being maintained in violation of federal law.
Once you understand how a pathetic liar thinks, the statements from Microsoft make sense. It is not the truth that matters. It is not whether it is right or wrong. The only criteria is whether it promotes the financial interests of Microsoft. If it does that, it must be true, right?
Their are many issues related to patents that really only come into play when the patents themselves are contested in court.
Being able to reproduce the invention would be one of those. And, there are many others.
The point I was making was that "trade secrets" and "patents" are the antithesis of each other.
Some things are better protected by trade secrets (perhaps file formats?) and others by fully disclosing but protecting by patents. Of course, not everything can be patented. A file format most likely would be one of those things that a patent would not apply to. There are design patents but I doubt those would extend to file formats.
The other point to mention here relates to comments coming from RedHat regarding their plan for patents. And, it would apply to any work done under the GPL too. If you fully disclose the source code either by a copyright filing or simply publication, there is not going to be any "trade secrets" involved. It is all disclosed assuming adequate documentation. I suppose the theory or concept behind a body of code could be a little obscure or difficult to understand simply from reading the code but for the most part those instances are rare. Of course the patent laws favor full disclosure anyway such that patent (and copyright) protections do apply to open source. Whether you charge for a license or not is a separate issue.
There may be many patents involved with products that also generate or use proprietary file formats but the patent itself can not protect the secrecy required.
And, why is that?
Patents and trade secrets are diametrically opposed to each other. You simply can not have a trade secret and a patent cover the same idea or concept.
The reason is that patents must fully disclose how to make the "object" and allow anyone following the patent information to do so. That is a fundamental requirement of a valid patent.
A trade secret on the other hand only works because that kind of information is keep from everyone else. So, the two concepts are fundamentally opposed.
That does not mean that software covered by a patent can not use proprietary and hidden formats. Rather it simply means that the file format is not covered by the patent.
It is certainly possible for a software program to be covered in part by a patent, covered in part by copyright and covered in part by a trade secret (non disclosed file formats). Copyrights might disclose enough information to "out" a file format but the entire source code does not to be part of the copyright application. Parts of it can easily be and usually are redacted to hide key parts. No doubt the code that actually generates the formats would be conveniently redacted out.
The real question is whether anyone should buy software that uses proprietary or non disclosed file formats. Clearly SUN (StarOffice) and OpenOffice.Org think it is a real advantage to not use a proprietary file format (XML). Microsoft thinks a proprietary one ties customers to their own product lines and thinks it is a great idea. But, it is only a great idea for the vendor not the customer. The customer would always be better off if a known format is being used and the known format is not proprietary. After all, the data belongs to the customer not the vendor of the code. And, the vendor should not taking any step which reduces the customers legitimate use of their own data. (Even if it strengthens the monopoly.)
what markets? Server or Desktop
on
United Linux is Here
·
· Score: 2, Interesting
UnitedLinux seems to finger the enterprise for its customers but fails to clarify which markets.
Is this effort targeted at the server market or the desktop market?
Since, they seem to finger Redhat I would assume the server markets?
You have to distinguish between illegal bundling of products and products being sometimes packaged.
There is nothing wrong with combining products from time to time or for some products.
The problem comes in when a lessor product is always bundled with a monopoly product.
Otherwise, that process does not always work. Redhat decided against including StarOffice simply because it would slightly increase the retail price for RedHat or cut into their margins. And, when you have to compete, raising your minimum price does not help you. That cuts into your sales.
That is also why you see Mandrake including StarOffice with some products but not with others.
It is not an absolute concept. And, it really is only harmful when combined with monopoly products that preclude competition.
Slashdot Mirror
I doubt you would reverse engineer anything for which you had the source code.
The difference is not whether you are assigned to fix a bug or you are a hacker attempting to take over a system.
The difference is only the means you have at your disposal. There is also a difference between an inside versus an outside attack.
If you are on the outside then having the source may or may not do you any good. If you are inside, then it makes it easy. And, that is why you have to understand the difference between having the source code or not.
But how do you control access to the source code of your key custom applications?
Do you discard it as soon as the first compile is successful? Or, do you keep it around for the ease in making futher changes?
The issues related to open and closed source are absolutely not identical.
Shrink wrapped applications compare to closed source for your OS.
Custom applications compare to open source on your OS.
That is how you must categorize the security issues.
I do not suggest you can not do similar things without the source code.
But, no developer I know of thinks that not having the source code is just as easily.
If that were true, you could just delete all those files for your custom apps and just edit the binaries once you get version 1 to boot up.
No one does that right? I mean absolutely no one. So, everyone agrees that modifing source code is the easiest way to make changes. That does not change just because it is an OS.
There is a big difference between open and closed source for your OS because of the security issues raised. (Forget about trying to prove the overall security is more or less because of that factor. I am well aware of the fact that an open sourced development process may very well result in more secure code. But, I am focused upon the specific security issues that an administrator needs to account for.)
The security issues related to the OS are similar to those related to applications. Is there a difference in the security issues for a shrinkwrapped application and a custom application written in-house? I do not think any administrator would think they are the same. If you have access to the source code for a key application in your business, you need to know how you treat security differently. You may do nothing about a shrink wrapped application. But, you should provide access controls for those applications for which you maintain the source code. And, you do that despite the fact that the public does not even have access to it. For your OS, the public also has it. So, how does that change your security efforts?
You also have to make a distinction between outside and inside attacks. As far as outside attacks go, once the OS is complied and installed you get what you get. If you want to argue that an OS developed in the open will result in superior code, I can agree with that. It is most likely true. But, that does not mean that open source does not create specific security risks that need to be addressed.
And, yes, many attacks can be engaged without the source code. But, no developer I know of claims that having the source does not make alterations easier. It clearly does. (Again, for the outside attack it may not matter if reading the code does not disclose a problem.) But, for the inside attack, having the source code opens up a whole range a easily implemented attacks.
And, the observation here is that once you begin to change the source code for the OS (or any application for that matter), you enter into a new level of administrative responsibilities. Now, any organization that does in-house development knows how to deal with those issues. The point being that with open source systems, those issues also relate to the OS itself.
The idea that a typical distro could be modified by a company, the changes kept secret and the modified version installed on all systems is just an example of what could be done. And, you do not have to alter any particular utility or function. You could just customize the log-on process with a custom version that would not be easily duplicated without having access to your code. Make your code private or secret (lock it away). And, then install the custom version. Besides there are any number of reasons why you might want to customize the version that employees boot up everyday anyway. The point here is simply that even with an open source OS you can benefit from a measure of additional security through customization and obscurity of what was done. And, perhaps in the process a simple way to allow any normal user to be given a warning is their "system" runs differently some day.
If you just install the standard RedHat distro but someone else makes their custom version and installs it on top of yours, you may or may not be aware of the change. The point being that you can customize the OS in such a way to put normal users on notice if things change. In other words, you can do things that help normal users serve as a "tripwire" as well.
The whole point here is that the security issues related to open source versus closed source are not identical at all. And, you have to understand how they differ.
I have no doubts what so ever that many can do wonderous things without source code.
But, it is also true that everytime anyone is assigned to correct a bug, fix a problem or alter the way a system works; the first thing they ask for is the "source code".
So, no matter what you do the source code makes it easier.
Now, that does not mean that a hacker out on the internet is going to benefit from having the source code to the OS you are running. That is an external attack. And, such an attack may or may not be made easier simply because of source code availability.
However, administrators have to also be concerned about "inside" attacks. Attacks coming from disgruntled employees or simply from those who might abuse the trust they have been granted.
And, that is where the difference between having access to the source code and not having that access makes a difference.
And, again I compare the security issues with those associated with custom in-house developed applications. What do you do with that source code? Is it controlled in any way? Do you post it on the company bulletin board? Do you publish it? If open source does not raise additional issues simply because of its availability, there would be no reason not to publish all your code, right?
So, while you can do wonderous things without the code, that does not mean that particular security considerations need to be taken into account when source code is available.
No.
If I assign you to correct a bug in a key application, I am sure you will demand to have access to the source code used to compile that application.
In other words, you know precisely what the difference is.
Your argument suggests that support staff do not need access to source code because they can do their jobs without it.
It simply is not true.
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.
Well. Sure.
But, I doubt anyone ever thinks that it is just as easy to alter a program with or without the source code.
Funny that all developers I know of demand that they be given source code to anything they are responsible for fixing. It is just a whole lot easier to do your work.
So, it is false to equate open and closed source when talking about security issues. The issues are not the same. They are very different.
Having exclusive access to the hardware (even overnight) does not equate them either. Those who might want to change the program always want to start with access to the code. It does not matter if it is the OS or a custom application. If they have to fix it, they want access to the code that compiles the program. If they want to hack it, they want access to the code that compiles the program. They are the same.
So does it matter if the source is open or closed? Well, to the kind person who wants to alter it, yes it does matter a great deal. Where you need to equate the security issues is between the source code for your custom applications and the source code for your OS. (Assuming you have both.)
Well. Sure.
And, yes I do assume physical access to the equipment.
But, the point was that security must be different simply because the source to the OS is open. Those with access are able to engage in a different selection of ways in which the systems can be attacked.
It is not a matter of whether open source is more less secure than closed source. Rather it is that the range of security issues are different. It is just like the range of security issues related to custom applications written in-house where many may have access to the code and shrink wrapped applications where access to the code does not exist.
The possibilities are a different set. And, the use or lack of the use of obscurity can change that set.
And, the "sets" do not become the same just because of the physical access either. They remain separate and distinct sets. Some events may very well appear in both. Some events or threats may only appear in one or the other. That was the point of making a comparision to the source code of key custom applications. There is a reason why banks do not publish the source code for all their key applications. And, it is not simply that they are proprietary. They may be. But, other reasons apply also.
Do not confuse this discussion with any effort to convince anyone that open source OSs are more or less secure than closed ones. Rather this discussion deals strictly with the issue that security is different when source code is open. And, if you draw that out a bit, the set of concerns can be changed by altering the code, compliling it, put it into use and removing the open code. Making it obscure, in other words, and gaining the value of the obscurity you placed on it. Not to be confused with the obscurity put into place by a vendor only selling binary copies.
You got the point.
But, your spouse does not need to shoot you to get your spare cash. All your spouse needs is "access".
And, the point I was making is that not all attacks come from the outside. Real security can not assume that.
Banks do not assume that only bank robbers will try to get their hands on the loot. They all know that employees are to be watched like a hawk. That is why they have to balance their cash drawers every day. It is not because the bank is afraid they are short or longing customers.
The old root password is not required to replace the OS.
Try it sometime.
Install your OS and use a different root password, right?
Oh, I agree that "features" can often come with some serious security problems. No doubt developers do not have the innovative mind necessary to foreclose possible abuses.
But, the issue I raised did not relate to exploits because the source was open. Rather they relate to the fact that almost anyone can have it.
If you run RedHat 7.3, the source for your OS is publicly available to all. Is that the same situation you find yourself in if you are a bank and are focused upon the ATM software you run? No. I do not think so. Your ATM software is not publicly available via download. Your OS might be.
So, the wise are aware of that and take that fact into account. Many do not. Many think that because many eyes look at the code before it is distributed that controlling access to the code used to generate your OS is not important. And, that depends upon who the other guy is. And, what he can do if he has the source for your system and the access to replace your OS. Having the source code means you can change anything you want. And, so can "he" or "she".
The source code for your OS needs to be guarded in the same way that source code for any key application needs to be guarded. And, that is more difficult to do if everyone has a copy of it.
..check out my web site before you speak next time...
Your sysadmin may be correct in not passing around the root password. However, the root password is not required in order to modify the OS (assuming your have the source somewhere laying around), install your bogus copy and begin collecting those "passwords" for as long as no one figures out the OS has been replaced.
Just remember, if the jerk getting his way with your system can alter the logon, the new code can make a note of any passwords entered and just "grandfather" you in. So, it may be a while before it is detected that bad passwords work just as well as the real ones. Most people I know can type their own password without mis-spellings quite easily. And, even if you think you may have hit the wrong key, when "your're in", your're in.
So, it really depends. 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.
When I talk about insiders engaged in serious attacks, I do not exclude the possibility that anyone with the root password may be involved. Disgrunted employees and SYSAdmins are not mutually exclusive, now are they?
Just who is the "boss" over your systems? The first answer is the last guy who installed the OS?
The risk is the same for a key application (that handles your money) and a key OS. Except all OSs
are key.
A few months ago I posted a number a few articles on my own web site about the security risk created by open source. No doubt a few /.ers recall finding out about the so-called attack upon open source and pried open their emailer.
/.ers failed to see the concept or consider how it could help them.
Problem was that it was not an attack upon open source at all but rather a rather strong suggestion that having the source code for an application or OS can have its downside. And, that is that anyone who has access to that code and your machine can modify it as they see fit. And, those modifications may not be with "your" approval (assuming you own the joint).
The point was that having source code comes with a price. And, that price is additional vigilance and perhaps some controls.
It is known that a sizable threat comes from within and not only over the internet or lan. And, those who are in a position to alter your OS or key application also have the ability to abuse that access.
As was pointed out above, if you have your own home grown or modified OS, it may be more secure against outside attack simply because of its obscurity. And, yes, obscurity can be security. Of course, once the cat is out of the bag, you are in trouble because of your insecure system, if that is the case. So, security by obscurity is only as good as the obscurity lasts.
Of course, the solution to the possible risk of someone else planting a Trojan in your OS could be modifying it yourself (making it obscure in key ways) and then hiding the source code. In other words, closing the source as far as your installation is concerned.
That does not reduce your security to that of a well known closed source OS but rather takes the better security offered by an open system, modifies the system to change its character and then sealing it against the world.
And, since it is easy to customize a log on sequence or process and then obscure the code, your custom changes would not only be more difficult to alter by a third party but any change they make may be easily detected by normal use.
Of course, the parade of
Or, indeed make an open source OS even more secure than when they got it. That would give you the benefit of the multitude of eyes upon the problem and the benefit of obscurity as well.
But, no I have not changed my opinion at all. Open sources does create certain security problems that need to be understood. And, perhaps even taken advantage of.
Funny how every time some one decides against a Microsoft product it is deemed as limiting choice rather than making a choice.
A government (or any customer) is fully within their right to discriminate against a vendor for what ever reason they may wish. And, that includes defective products, inferior products, insecure products, proprietary products or simply the use of illegal means to preclude competitors.
The US government should take the same approach as indicated by Germany, France and Peru.
If you are going to be spending the people's money it should be for products not simply padding a single corporation's wallet.
I have email from individuals suggesting that I should not discriminate against Microsoft just because they are violating Federal Law.
But, that is a perfectly legitimate reason for doing so.
Actually, the use of linux has received its start from the bottom up. But, the numbers are hard to come by.
Many professionals in IT have started using linux on their home and personal systems for many reasons. And, when they find (found) that open source systems work just fine and can contribute, those technologies have worked their way into corporate systems.
But, the major bump will first come when the top companies in the industry openly support a linux/unix solution across all systems including the desktop.
It is stupid to sell Microsoft desktops and linux/unix servers when Microsoft designs its technology to harm those customers who try to benefit from non-Microsoft technology.
IBM, Hpaq, DELL, SUN, Gateway and others have to wise up and avoid the companies that design its products to interfere with the effective use of the technologies out there. And, that is precisely what Microsoft is doing. So, Microsoft is the company to avoid.
If I had nothing intelligent to say, I would not use my own name either.
It is a good question whether IBM is going to support linux desktops under this deal.
I have often commented that linux on the desktop will have fully arrived when companies such as IBM, Hpaq, DELL, Gateway, SUN and others fully support the linux desktop as part of the full solution.
SUN (surprisingly) may be the first major company to do so openly. DELL tried and Gates illegal acts caused them to stop. Hpaq and others may make a deal here and there for linux systems. But, only when the companies actively promote the linux/unix (desktop/server) combination will the linux desktop really take off.
The technology is there. SUN's StarOffice is right there. Other office suites are also available. (Maybe, Corel will even reverse course and again offer WordPerfect Office on linux?)
And, with Lindows and Xandros both about to bring out their distros focused upon the desktop use of a PC (rather than a server), perhaps a few of those OEMs will seriously consider a promotional campaign.
The corporate accounts will come first. With Java and Delphi/Kylix as well as other development environments making cross platform applications feasible, corporate accounts can easily adopt a linux desktop or linux/Microsoft solution.
What is very clear is that Microsoft will design its products to harm those customers who try to use non-Microsoft products. That policy is dead obvious. And, it is directed at preventing non-Microsoft products from having fair and open markets. That is why Gates took the baseball bat to DELL. Microsoft's policy is to harm those customers who use other technology.
So, the quicker customers move off of Microsoft the better off they will be.
Microsoft and its spokespersons are so pathetic because they never use the truth or logic to propound or support their statements.
Microsoft is a typical pathetic liar. A pathetic liar is one who only judges what they themselves say based upon how good it feels when they hear themselves talk.
For Microsoft, anything that sounds like it may promote Microsoft's interest is classified as being true and correct without any evaluation of whether or not the statement is actually true or false.
The same applies to "right" versus "wrong" as far as morals and violations of laws are concerned. There is no independent determination of whether something is legal or not. It is helps (or appears to help) Microsoft, then it is presumed to be legal and therefore implemented.
That is why Bill Gates beat up on DELL to stop their promotion of desktop linux systems. That is why all of their illegal acts where approved at the highest level. There was no moral judgment.
That is why Bill Gates and Microsoft make the dumbest statements.
Under oath Allchin claimed that somehow the GPL was in part responsible for not including a SUN compliant JVM with XP. Never mind that SUN does not even use the GPL for Java. The importance to Allchin in making the claim was to bad mouth SUN and the GPL under oath even when the statement does not make any sense at all.
Under oath Gates and two other witnesses claimed that temporarily removing a few icons is what was bothering the court of appeals when they found that commingled code violated the antitrust laws. I guess the idiots at Microsoft do not know the difference between an icon and source code? Clearly their lawyers must since they tried to ask the court of appeals to take a second guess at the commingling issue. They said, "no", we meant what we said. So, Microsoft lies about the decision and fabricates a fake remedy claiming it is responsive while any one knows the benefit of the illegal commingling is being maintained in violation of federal law.
Once you understand how a pathetic liar thinks, the statements from Microsoft make sense. It is not the truth that matters. It is not whether it is right or wrong. The only criteria is whether it promotes the financial interests of Microsoft. If it does that, it must be true, right?
Yes. I believe you are correct.
Their are many issues related to patents that really only come into play when the patents themselves are contested in court.
Being able to reproduce the invention would be one of those. And, there are many others.
The point I was making was that "trade secrets" and "patents" are the antithesis of each other.
Some things are better protected by trade secrets (perhaps file formats?) and others by fully disclosing but protecting by patents. Of course, not everything can be patented. A file format most likely would be one of those things that a patent would not apply to. There are design patents but I doubt those would extend to file formats.
The other point to mention here relates to comments coming from RedHat regarding their plan for patents. And, it would apply to any work done under the GPL too. If you fully disclose the source code either by a copyright filing or simply publication, there is not going to be any "trade secrets" involved. It is all disclosed assuming adequate documentation. I suppose the theory or concept behind a body of code could be a little obscure or difficult to understand simply from reading the code but for the most part those instances are rare. Of course the patent laws favor full disclosure anyway such that patent (and copyright) protections do apply to open source. Whether you charge for a license or not is a separate issue.
There may be many patents involved with products that also generate or use proprietary file formats but the patent itself can not protect the secrecy required.
And, why is that?
Patents and trade secrets are diametrically opposed to each other. You simply can not have a trade secret and a patent cover the same idea or concept.
The reason is that patents must fully disclose how to make the "object" and allow anyone following the patent information to do so. That is a fundamental requirement of a valid patent.
A trade secret on the other hand only works because that kind of information is keep from everyone else. So, the two concepts are fundamentally opposed.
That does not mean that software covered by a patent can not use proprietary and hidden formats. Rather it simply means that the file format is not covered by the patent.
It is certainly possible for a software program to be covered in part by a patent, covered in part by copyright and covered in part by a trade secret (non disclosed file formats). Copyrights might disclose enough information to "out" a file format but the entire source code does not to be part of the copyright application. Parts of it can easily be and usually are redacted to hide key parts. No doubt the code that actually generates the formats would be conveniently redacted out.
The real question is whether anyone should buy software that uses proprietary or non disclosed file formats. Clearly SUN (StarOffice) and OpenOffice.Org think it is a real advantage to not use a proprietary file format (XML). Microsoft thinks a proprietary one ties customers to their own product lines and thinks it is a great idea. But, it is only a great idea for the vendor not the customer. The customer would always be better off if a known format is being used and the known format is not proprietary. After all, the data belongs to the customer not the vendor of the code. And, the vendor should not taking any step which reduces the customers legitimate use of their own data. (Even if it strengthens the monopoly.)
UnitedLinux seems to finger the enterprise for its customers but fails to clarify which markets.
Is this effort targeted at the server market or the desktop market?
Since, they seem to finger Redhat I would assume the server markets?
You have to distinguish between illegal bundling of products and products being sometimes packaged.
There is nothing wrong with combining products from time to time or for some products.
The problem comes in when a lessor product is always bundled with a monopoly product.
Otherwise, that process does not always work. Redhat decided against including StarOffice simply because it would slightly increase the retail price for RedHat or cut into their margins. And, when you have to compete, raising your minimum price does not help you. That cuts into your sales.
That is also why you see Mandrake including StarOffice with some products but not with others.
It is not an absolute concept. And, it really is only harmful when combined with monopoly products that preclude competition.
I believe Adabase is the data base included in Star Office.