Re: retranslation

Leif
>2) many vendors (most!) ship products that
> are created on earlier releases with no observability.
If they want to sell their products to V5R2 customers, then V5R2 customers
can make this a requirement. I think these new enhancements gives OS/400
customers tremendous leverage over ISVs that hasn't been possible before.
These new enhancements can be used by customers to force ISVs to up-front
about security related monkey business.

> 3) how do we know that the translation template has
> not been monkeyed with? I know your answer
> will be that that is impossible,
No Leif, you are wrong. You are a very technically talented individual, but
as a mind reader you have a long way to go. I must say it is hard to have a
debate with someone that argues with your answer before you answer ;-) This
is not my answer.

My answer is...It is certainly possible to hack creation templates.
However, it is not possible to hack them in a way that will cause the
"trusted" translator in SLIC to generate code that defeats the integrity of
the system.

The way to break this would be to hack the trusted translator. But if you
control who has access to Display/Alter/Dump (as we have always suggested
and as we have made even easier to do in V5R1 and V5R2), and retranslate
every executable that comes on the system, then the threat from someone
hacking the translator is limited to only those who you have explicitly
given the ability to hack the trusted translator.

Leif, you keep arguing that security on OS/400 is not 100%. I agree with
you. Nothing related to security in the real or virtual world can be 100%
and still be useful. It's a bit like a prison. You have to have guards and
you have to trust the guards. So you had better have a good guard hiring
process. Does this mean the prison isn't secure (or more appropriately,
securable)? I argue strongly no. If you have two prisons, the more secure
prison is the one that requires fewer guards to guard the inmates. How much
does it cost you to secure the prison is the relavent question, not how
secure the prison is.

This thread could go on forever with "but if I bamboozle the help desk,
and..., then I can break into your system?" I believe whatever you come up
with, I can come up with a scenario to avoid that problem. The real issue
is not that you can come up with a scenario, and not that I can point to
ways to avoid that scenario. The real issue is how much does it cost you to
manage your system in a way to avoid that scenario. I still think OS/400
comes out on top when compared in this way to *nix and windoze systems.

Patrick Botz
Senior Software Engineer
eServer Security Architect
(507) 253-0917, T/L 553-0917
email: botz@us.ibm.com




                      "Leif Svalgaard"
                      <leif@leif.org>           To:       
<midrange-l@midrange.com>
                      Sent by:                  cc:
                      midrange-l-admin@m        Subject:  retranslation
                      idrange.com


                      10/30/2002 02:44
                      PM
                      Please respond to
                      midrange-l





From: Patrick Botz <botz@us.ibm.com>
> A much better alternative is to always retranslate anything that comes on
> your system and not let it on if it can't be retranslated
>
> You can do this today in V5R2.

1) many people (most!) are not on V5R2.
2) many vendors (most!) ship products that
are created on earlier releases with no observability.
3) how do we know that the translation template has
not been monkeyed with? I know your answer
will be that that is impossible, but that was the
answer to many of the earlier problems too:
Can passwords be cracked? Impossible!
Can pointers be counterfeited? Impossible!
Can program validation value be faked? Impossible,
etc.

But, as Yogi Bear said: "this time for sure!"


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.