I want to respond in a positive way Leif.  I believe it is important to all
of us to understand the thrust of your investigations and knowledge.  We
need to make balanced decisions.

My first reaction is one of horror and disbelief but once I am past that I
look at the empirical evidence available to me.  The World and my own
experiences teach me that the AS/400 has the best uptime, flexibility,
life-cycle, and disaster-recovery.  Its vulnerbility may be open to debate,
but its track record of viruses and security is among the best in the World
for commercially available business solutions.  I conclude that internal
sabotage is the area of weakness and that seems to be what you are saying,
too.  This is no big surprise.  All platforms have that trouble.

More importantly though, you have pointed out some really  major weaknesses.
  Single Level Store has worked to stop lots of other kinds of attacks, so
maybe it should be kept, but a way found to resolve the weaknesses you've
isolated.

One point I wish you would make for my benefit though is: Who's doing
security better, in a commercial environment?


---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@MartinVT.com
---------------------------------------------------------

-------Original Message-------

From: midrange-l@midrange.com
Date: Tuesday, October 29, 2002 01:34:36 AM
To: midrange-l@midrange.com
Subject: Fix Security (was: Paging file)

From: Steve Landess <steve_landess@hotmail.com>

> SO, what is the solution to the problem, Leif?

>

> I have begun reading your eBook. I was particularly interested in how a

> program can switch into system state and use fake pointers, and I hear you

> talking about the flaw(s) in SLS.

>

> What can IBM do to fix it? Create a new level of system security?

>


There are several things that contribute to the lack of security:
1) the single-level-store that guarantees that once you have
the "keys to the kingdom" you can go everywhere
2) the sloppy, or inexperienced, or (pick your favorite excuse)
mixing of privileged and un-privileged information. E.g. that the
MSR (Machine State Register) is stored in user-accessible
storage (albeit with a fake pointer)
3) the flaw that the system tries to DETECT rather than PREVENT
misuse and faking of pointers. The detection can be gotten around
(cf. chapter 7)
4) the belief that the various checksums cannot be broken and
faked out (general arrogance)
5) and more...

The first thing to do would be to clean up the design so that
the MSR is stored in a separate (protected space). I have it
from good sources that this process has started. There may
be more types of "privileged" modes coming (i.e. more bits in
the MSR), and so on. These things require hardware changes
so do little for the installed machines. The first step is to accept
that thee AS/400 is security-challenged and then constructively
do something about. As long as the developers (and maybe
more their managers) believe the marketing hype about the
absolute invulnerability of the system it will be nard to make
progress, but there seems to be improvement on its way.
Maybe the AS/400 on its deathbed will finally be secure...





_______________________________________________
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.

.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

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.