While in principle I can agree with what you're saying, this is a pretty insulting view to take of all the people who work on GNU/Linux distributions. (Or put another way, how am I better than every Debian developer combined? (Substituting Debian for your distribution of choice, of course.))
It doesn't have to be insulting to them. What authentication mechanisms are supported in my environment? What, based on our security policy, do we not allow? Have the RedHat/Debain/whomever developers taken that into account? Of course not, they can't. They can merely put together a package which works well for most typical users.
For Open Source in the enterprise, you really need to be willing to customize this stuff to fit your environment, not fit your environment to what has been given to you. Yes, it takes having people who know what they are doing, but the end result is better. I contend that it takes admins who know what they are doing anyways to run things well.
I use RPMs for ensuring I've got a stable base upon which to build. Anything listening on a socket is compiled from source, with things turned off that aren't used in our environment, and things turned on which are used. A text file is placed in/usr/src which documents the options passed to configure, make, etc. It's easy for anyone to hop on and see how something was built, or re-use the flags when building a newer version.
Because the base is consistent, it's easy to test new things on a test box before deploying it in production.
For many shops, RPMs may get the job done. It's been too limiting for me in at least a couple of cases, so I don't go that route -- it just takes a bit more discipline as far as documenting things, but it's hardly unmanageable.
If you're responsible for the machines you run how can you abdicate that responsibility by using whatever some package maintainer decides to give you?
I agree. Except for the most simple minded of applications someone else has made decisions for you if you use rpms. Maybe those decisions are good enough, but maybe they aren't. The only way to be sure is to grab the source and build it for yourself. I'm building things to be used by 1-2 thousand concurrent users, so I do care about that extra 5% performance improvement.
As important, if not more important, is that building from source allows you to turn off features you're not using. This can improve security by offering fewer chances for buffer overflows and such. Also it may improve performance.
Then I got sick of Solaris, since it reminds me too much of my days working at Genuity. Talk about nightmares... everytime I sat down at the computer I felt my old PHB asking me for a status update and a team schedule and to update my bug reports.
Did you get the memo about the TPS reports?
I don't think that security holes reduce the EAL rating. If they were to do so, only holes that existed in the certified configuration should be considered. A security certification can't possibly tell you that a system is secure in every concievable configuration.
Any moron of a sysadmin can take a very secure system and turn it into one full of holes. Conversely, the best sysadmin in the world can't make a poorly designed system secure. A certification gives you, a non-moron of a sysadmin, some hope that you can lock a system down to a point where it's "secure".
As much fun as it is to slam Microsoft (hey, I do it all day long), it is possible to configure Windows so that it is pretty secure. You have to disable most all of the network services, but it can be locked down... The NT kernel itself was designed with a lot of good security features. Those DEC guys did a great job. Now if only the rest of Microsoft could learn how to design software with security in mind from the outset, and stop introducing "improvements" which make the OS less secure (tying everthing in the world to Internet Explorer, for example)...
see, this shotgun used to belong to your daddy. Before that, it belonged to your daddy's daddy. We got this idea to hijack an airliner, but as you know everyone travels naked on airplanes. So, I wore that shotgun, up my ass... And now I give it to you.
Slashdot Mirror
It doesn't have to be insulting to them. What authentication mechanisms are supported in my environment? What, based on our security policy, do we not allow? Have the RedHat/Debain/whomever developers taken that into account? Of course not, they can't. They can merely put together a package which works well for most typical users.
For Open Source in the enterprise, you really need to be willing to customize this stuff to fit your environment, not fit your environment to what has been given to you. Yes, it takes having people who know what they are doing, but the end result is better. I contend that it takes admins who know what they are doing anyways to run things well.
I use RPMs for ensuring I've got a stable base upon which to build. Anything listening on a socket is compiled from source, with things turned off that aren't used in our environment, and things turned on which are used. A text file is placed in /usr/src which documents the options passed to configure, make, etc. It's easy for anyone to hop on and see how something was built, or re-use the flags when building a newer version.
Because the base is consistent, it's easy to test new things on a test box before deploying it in production.
For many shops, RPMs may get the job done. It's been too limiting for me in at least a couple of cases, so I don't go that route -- it just takes a bit more discipline as far as documenting things, but it's hardly unmanageable.
I agree. Except for the most simple minded of applications someone else has made decisions for you if you use rpms. Maybe those decisions are good enough, but maybe they aren't. The only way to be sure is to grab the source and build it for yourself. I'm building things to be used by 1-2 thousand concurrent users, so I do care about that extra 5% performance improvement.
As important, if not more important, is that building from source allows you to turn off features you're not using. This can improve security by offering fewer chances for buffer overflows and such. Also it may improve performance.
Then I got sick of Solaris, since it reminds me too much of my days working at Genuity. Talk about nightmares... everytime I sat down at the computer I felt my old PHB asking me for a status update and a team schedule and to update my bug reports. Did you get the memo about the TPS reports?
Any moron of a sysadmin can take a very secure system and turn it into one full of holes. Conversely, the best sysadmin in the world can't make a poorly designed system secure. A certification gives you, a non-moron of a sysadmin, some hope that you can lock a system down to a point where it's "secure".
As much fun as it is to slam Microsoft (hey, I do it all day long), it is possible to configure Windows so that it is pretty secure. You have to disable most all of the network services, but it can be locked down... The NT kernel itself was designed with a lot of good security features. Those DEC guys did a great job. Now if only the rest of Microsoft could learn how to design software with security in mind from the outset, and stop introducing "improvements" which make the OS less secure (tying everthing in the world to Internet Explorer, for example)...
see, this shotgun used to belong to your daddy. Before that, it belonged to your daddy's daddy. We got this idea to hijack an airliner, but as you know everyone travels naked on airplanes. So, I wore that shotgun, up my ass... And now I give it to you.