Hi  all

If you haven't already,   you ought to  try this  forum.    It has some
interesting things on it including the 
following(below).    

The site is;   http://forums.infoworld.com/threads/get.cgi?6305

Maybe someone else would care to add their perspective on the security
issue(maybe about the AS/400)   

Thank you 
John Carr

---------------------------------------------------------------------------
--
Can NT ever be secure?

     Posted by: n.petreley
     Date posted: Mon, 13 Jul 1998 

     Here's are some interesting viewpoints and some insights by Carmine
Mangione, which I
     received via email, and am posting here with his permission. Just a
quick note: the issue about
     NT 4.0 and orange book is one of timing. The question isn't if
Microsoft never submitted NT
     4.0 - the question is, did Microsoft tell potential customers NT 4.0
was in RAMP before it
     actually was? 

          First, Microsoft did submit NT 4.0 for certification for
orangebook. The
          status has been 'pending' for about 18 months--at least since I
researched it
          at Redmond Communications. After much research, including talking
with
          the person at the NSA responsible for certifying NT was that MS
dropped
          the ball--didn't respond to any of the problems with NT. I
strongly suspect
          that the incusion of COM and DCOM as core, inseperable services
in NT
          makes it unlikely that NT 4.0 as it stands will ever be
certified--COM and
          DCOM subvert NT's security object model. In addition, the new
graphics
          model is fundamentally insecure. Ring 3 process essentially have
access to
          ring 0 data without passing through the security layer--very bad.
This
          change alone dooms NT 4.0 to non-certification.

          The other problem is that no code can be added to the base system
without
          re-certification. This is extrememly difficult when you release
beta products
          as final version.

          Second, Microsoft has always willfully misrepresented their
security. The
          person responsible for pushing NT as a secure system didn''t even
          understand the distinctions between the various security levels
and was of
          the opinion that if NT 3.5 was secure that NT 4.0 should be more
          secure--after all it is newer. This seems to be the prevailing
attitude at MS. 

          Finally, NT will NEVER be redbook secure. The reason is that
redbook
          requires that secure objects identify themselves remotely and
that this
          identity must be unique--this prevents spoofing. NT does not do
this, nor is
          it really possible to put it in without a major redesign and
rewrite of the
          kernal. Perhaps this is why MS has essentially given up. If you
have to lie
          about security, why not go all the way.

          Ironically, most of NT's performance problems can be traced to
the
          addition of the kernal object model, created for security. The
lightweight
          remote procedure calls (LRPC) into the win32 subsystem for secure
access
          to NT Kernal objects is responsible for the size, weight and
ponderous
          nature of NT threads.

          There was a grand scheme during initial development that this
would help
          them to attain B level security--Cutler's grand scheme. Now we
are stuck
          with the poor performance difficulties no security. Wow, the
worst of both
          worlds.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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 here. If you have questions about this, please contact [javascript protected email address].