You're arguing at completely cross purposes to what I posted.  We had been
discussing error messages, and how self-explanatory they are or not.  Phil
Payne then made a side-comment that "In enterprise environments code and
operations are separated for audit and control reasons."  That goes well
beyond error messages and how readable they are, or how you look them up.

My point was and is that for a _large percentage_ of what runs on a Linux
system, source is available to anyone that wants it.  (I don't think that's
any surprise to anyone, let alone the OCO-only software suppliers.  They
know very well that they're Linux-based products run on systems that are
mostly Open Source.)  If an operations employee wants to try to figure out
where a system might be vulnerable to a buffer overflow exploit (remote or
otherwise), they'll be able to do it.  No audit policy or auditor is going
to be able to stop that, given that the shop is running on an Open Source
platform.  (The flip side is that such exploits are found more frequently
and fixed, but that's neither here nor there for the purposes of this
discussion.)  It may be a reason why a shop decides to not run an Open
Source platform, but again, that's an irrelevant point given the initial
condition that it _is_ running such a platform.

So, given that _all_ employees of an enterprise are going to have access to
the source of your operating system, and a lot of the other software that
runs on it, the people responsible for those systems cannot hope for
security through obscurity.  They will have to assume they're in a hostile
environment (80%(?) of all system intrusions are from employees, as I
recall) and act accordingly.

Mark Post


-----Original Message-----
From: Nick Gimbrone [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual


> 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.
As I understand it you are saying that if the message isn't documented and
isn't
understandable then you get to read the source to figure out what it
means... to
me (and I think to many other computer professionals and software users)
that is
a big shortcoming of the software (that it does not produce output that can
be
understood short of reading the internals that produced it).

>  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.
I guess that is going to come as a big surprise to all those companies that
produce OCO products... which is every company I've worked for since 1992
(and
each of those companies produces software that sells into systems that
include
open source components)... this includes the device drivers for Linux on
390s
too, which from the traffic on this list are clearly a source of issues.

>  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.
No auditor that I have ever known of would just accept it if it represents a
risk that is unacceptable to the company... they will assign a cost to that
risk
and let management make the managerial decision as to if that
cost/risk/benefit
trade-off should be made or not.

Indeed, one of the costs that they should be examining is what the
operational
costs are (e.g. if operations staff have to read 20-100K lines of source to
understand a message, then they will need a new and more sophisticated
background... and that means that they will not only have less time to do
the
other aspects of their job (because researching the meaning of a message now
takes longer), but they will also be more expensive resources (and likely
harder
to fill positions... few who can understand raw C will want to work in
operations I'd predict).... These all represent real risks to the business!

> 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.
But "Linux & the Open Source products that run there" are not the only
source
(sorry ;-) of the "cryptic message" (as well as the highly related "cryptic
help
system" ;-) problem... if you ment to restrict your original comment to just
these system, then I'm sorry that I misread your posting (though I still
don't
agree with it ;-).

Peace. -njg

Reply via email to