Greetings; For all practical purposes securing source so that only authorized people can modify it is for all practical purposes the same as denying all source to everyone. At least for all the open source software that you use.
For the vast majority of things that execute on your system the same source is freely available to anyone. And they can compile it using the same compilers and linkers that you do. If they can get the executable onto your system, then the inconvenience of having to get the source somewhere else was just that, and a minor one. The real problem is to ensure that what gets executed is what is meant to be executed. And this isn't as easy as it seems. There are all sorts of clever ways to get a program somewhere in the /home tree to be executed in place of the "real" one in /usr/bin. And a further complication is that maybe the perp isn't interested in transferring the company bank account to a numbered account in Switzerland, or having a new entertainment system shipped to their house, free of charge. Maybe they just want to completely ruin your life sometime in the next year or so! (ie. Thay have already done it, but you don't know it ... yet!) Good Luck & Sweet Dreams! Dennis "Ward, Garry" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 01/31/2002 11:04:42 AM Please respond to Linux on 390 Port <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Messages Manual Securing source so that only authorized people can modify it is not the same as denying all source to everyone. Any system, open source or not, should have the security functions available to ensure that only properly authorized people can modify the programs and scripts running in it. The issue is setting the security up and properly identifying the who is in the authorized group and who isn't. Of course, on my personal computer at home, I'm always in the authorized group. But we are not talking about personal computers at home, we are talking about production systems that businesses rely on for the daily operations. -----Original Message----- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 11:15 AM To: [EMAIL PROTECTED] Subject: Re: Messages Manual Nick, I understand the reasons for auditors (having been involved in audit compliance myself for a while). I wasn't talking about any "shortcomings" in the software. The fact is that source for nearly everything running on any Linux system is available. Operations folks are going to be able to get access to that source. Period. No auditor in the world is going to be able to change that, so they might as well face up to it and deal with it. Keeping the source for applications, VM and MVS away from operations workers was and still is feasible, but not for Linux and the Open Source products that run there. Mark Post -----Original Message----- From: Nick Gimbrone [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:52 AM To: [EMAIL PROTECTED] Subject: Re: Messages Manual > That's going to be pretty tough to do for Linux/390 shops, unless they're > allowed to maim their operators by blinding them. :) Not something I would > recommend, in any case. I think auditors are going to have to change their > mindset a little in this area. Auditors exist for business reasons. Support computer systems exist for business reasons too. I think it is a little backwards to assume that shortcomings in software that might cause it to not meet some of the business needs mean that the auditors should abandon their goal of making sure that these systems meet the business needs... It is (for some businesses) the "right" thing for operations and development to be segregated to the extent that operations has zero access to the code. Just because some software does not make this easy does not mean that the goal should be abandoned. -snip- <font size="1">Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
