> Sigh, here we go again. I would think by now the issue of using
> Logon-UDCs as a security mechanism would be well understood. I have a
> suggestion - surf over to bit.listserv.ibm-main and post a query asking if
> Logon-UDC type authentication (don't sugar coat it, be sure to mention the
> shortfalls) would be an acceptable control mechanism. I know the answer
> you'll get!

bit.listserv.ibm-main?  Why would I ask them about an MPE security mechanism?

Just because some IBM OS has a mechanism that is superficially similar to
LOGON UDCs doesn't mean it's the same.

Eugene Volokh used to say (and probably still does): "Don't confuse things
with other things."

> A good resource in gaining basic understanding of computer
> security is the U.S. Department of Defense Rainbow Series. When MPE V was
> evaluated for C2 certification the question was asked about using a
> Logon-UDC mechanism and the evaluators said no-way. And for some very good
> reasons - take a look at the Orange Book and its brethren. The bottom
> line: Authentication, access control and auditing should be implemented at
> the operating system level - Logon-UDCs are user level.

Been there, done that.  One of my projects at VESOFT was to take
SECURITY/3000 through the C2 certification program.  We didn't complete the
process for a number of reasons (probably a lot of the same reasons HP has
for not re-certifying new versions).  I learned a lot of things:

The DoD standards say a lot less than people seem to imagine they do, and the
vast bulk of it is bureaucratic nonsense.  It's not (by any stretch of the
imagination) a blueprint for implementing any form of computer security.

"Operating system level" and "user level" are not precise technical terms, they're
vague descriptive terms.  You've expressed a personal opinion, not a fact.

> In Michael's defense I have to say that we too went through an education
> process both in terms of understanding that there are more access paths to
> the system than just the HELLO command, and understanding well developed
> computer security practices in large commercial environments. That's why
> SAFE's conceptual roots can be traced back to RACF/ACF2.

The mechanism by which identity is verified at logon time is just one small
part of a "well developed computer security practice" -- a whole lot of
security has more to do with company policies and practices, etc.

> Just a couple of other points
>
> Michael D. Hensley wrote:
>
> > Execution of the OPTION LOGON UDC(s) is part of the login process; the
> > login has not been completed until the OPTION LOGON UDC(s) have been
> > executed (by definition).
>
> The execution path of some network logons (for example but not limited to:
> RPC, RDBA, RFA, FTP) complete an MPE logon, but do not execute the
> Logon-UDCS.

NS/VT and TELNET connections comprise one door into the system (although it
is the "main entrance") -- a door which can be safely protected by LOGON UDCs
(even if you choose not to buy a third-party package).  Other doors can be
protected in other ways (or "nailed shut") -- again, without purchasing any
third-party software.

My point is: the third-party packages are quite valuable.  But I still
consider it a myth that you can't adequately secure an MPE system without one
of them.

> And this is aside from problems such as someone edited the system-wide
> Logon-UDC and then forgot to do a SETCATALOG (oops!).

You're saying it's impossible to mis-configure SAFE/3000?  Or to turn it off,
and forget to turn it back on?  Wow!  What a technological breakthrough!

(For those who don't know, it's even easier to disable AIF:PE, and much more
difficult to tell whether or not is enabled.)

> > > Yes, this is the implementation that
> > > SAFE/3000 has used since MPE V up through MPE/iX. $PLUG off$
> >
> > No you haven't.  AIF's didn't exist on MPE V!  :-)
>
> Bzzzt! Wrong answer! Monterey Software implemented a version of AIF:PE
> under MPE-V/E in 1988. That's why SAFE has always enforced authentication,
> access control, and auditing at the operating system rather than the user
> level.

No, you didn't.  AIF:PE is a set of HP API's.  Monterey Software did some
remarkable things with MPE/V (and quite possibly developed a better set of
pre-logon "hooks" than AIF:PE provides), but I don't see the point in calling
it a "version of AIF:PE".  You might as well call Unix a "version of MPE":
they do similar things!

And you're assigning things to arbitrary, not-formally-defined "levels"
again.

There is an OSI 7 layer model for network communications.  It's quite
rigidly, formally defined.  And people still don't always agree on what level
particular protocols exist at.  That's with a widely agreed-upon model.  When
you invent your own model, and don't even define it, saying that something
occurs at one level and something else occurs at another level is very useful
(from a technical standpoint -- from a marketing standpoint, it's probably
quite useful).

> > Also, if you are using AIF's to intercept all file system calls (in
> > order to do your logging), the CPU overhead can be quite high (not as
> > high as the MI, perhaps...).  Since MPE can already log all file
> > accesses for you, I'm not sure what you'll gain in return for the extra
> > performance penalty.
>
> There are several security related items SAFE provides which auditors and
> systems managers find very useful in a large commercial security context.
> True you have to pay a resource tax to get this information. I've looked
> at it for SAFE and we have good performance compared to MPE log files.
> Since you worked for VESOFT I'll have to trust the above judgment
> regarding SECURITY/3000's resource consumption in this area.
>
> Anyone else who is (still) interested in this topic feel free to contact
> me for details etc.

A private message from a satisfied SAFE/3000 user confirms the low overhead.
Good job, Lee!

My main point was to disagree with Lee's contention that an MPE system, "out
of the box", can't be made secure.  I very strongly disagree.  The various
third-party packages (sometimes even used in combination) provide a great
deal of added value, but (IMNSHO) it's nothing less than marketing hype (of
the FUD variety) to claim your data is insecure without them.

Lee, you've got a good product with a number of unique features.  It has
survived in a market that has seen the disappearance of a lot of competing
products.  Drop the excessive hyperbole and sell your real strengths.  (It's
someone elses turn on the soapbox now...)

---
Michael D. Hensley       | mailto:[log in to unmask]
Allegro Consultants Inc. | Visit scenic http://www.allegro.com
408/252-2330             | "Support Bill of Rights Enforcement"