|
midrange.com
The trusted translator will not generate untrusted code from "hacked"
creation templates. So while it is possible to change the behavior of a
program by only having the creation data, it is not possible to change it
so that it bypasses system integrity and therefore poses no more (or less)
of a threat than any other program you choose to restore to your system.
You don't have to always run your system at option "7" either. One of the
great uses for this is when installing software from a vendor that you
perhaps have not installed before. If the vendor is not hacking the binary
code, then the code will work correctly even if everything is retranslated.
If the vendor doesn't tell you they patch code or tells you they don't
patch code, turning on option 7 when you install their application the
first time will prove whether or not they have. If you have vendor software
that you've used for years and trust, you might not bother to set the value
to "7" when installing new versions of that application. Or you might
install the new version on a test system with option "7", do your testing,
and then install it to a production system that has a more relaxed setting.
Should you allow vendor code that includes patched programs on your system?
Well, that's up to you. Your risk of unplanned downtime and unavailable
applications grows pretty large if you do...user beware. It costs a lot of
money to determine that a prolem is related to patched vendor code.
There is great potential value for customers (or a subset thereof) using
option "7" at least some of the time. However, you're not forced to use it.
Patrick Botz
Senior Technical Staff Member
eServer Security Architect
(507) 253-0917, T/L 553-0917
email: botz@xxxxxxxxxx
"James H H
Lampert"
<jamesl@xxxxxxxxx To
om> <midrange-l@xxxxxxxxxxxx>
Sent by: cc
midrange-l-bounce
s@xxxxxxxxxxxx Subject
RE: QFRCCVNRST
02/26/2004 04:59
PM
Please respond to
Midrange Systems
Technical
Discussion
> This is why the split up of observable data between debug & creation
> data was introduced, along with the ability to remove these
> observabilities individually.
>
> QFRCCVNRST can cause the recreation of the "executable" from the
> creation data. IBM forewarned of this a few releases ago, I think in the
> Memo to Users.
>
> If you are still creating programs on or for an old release (V2R3 IIRC)
> then these won't have the observability split up.
Seems to me that, considering as how (I'm told) it's POSSIBLE to
disassemble even a totally non-observable *PGM, creation data would be as
big a hole in proprietary commercial code security as debug data.
--
JHHL
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
