× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Level 40 Security Verses Level 30
  • From: John Earl <johnearl@xxxxxxxxxxxxxxx>
  • Date: Sun, 12 Dec 1999 14:20:07 -0800
  • Organization: The PowerTech Group

Arlene,

Arlene M Soderlund wrote:
> 
> In the Future We will be running an application that will need the HTML Server
> up and access to the Internet.  Of course IBM Security Manuals just say go to
> 40.   What insights for problems does anyone have about Level 40 security to 
>say
> standard RPG jobs that adopt user authority.   How does it change profiles
> authority or authority Lists.

The good news is that a level 30 to level 40 jump does not
involve changes to any profiles or authorization lists, and
has absolutely no effect on programs that adopt authority.

Qsecurity Level 40 has two principle benefits over level 30
Security.  First, some well known holes regarding Job
Descriptions were plugged, and second the differences
between System State and User State programs are inforced (a
potentially big hole most likely to be exploited by your
application vendors).

The JOBD hole that level 30 addresses has two
manifestations.  The first is that a user could submit a job
using an existing JOBD and have it run under the user
profile that is named in the JOBD.  If you have any JOBD's
on your system with user profiles attached, or if anyone has
the ability to restore a JOBD with a user profile attached,
then your level 30 system is vulnerable to this situation
(hint: IBM ships JOBD QBATCH with User Profile QPGMR
attached).  The second is where a JOBD can be specified on a
Subsystem's Device description so that users could get on to
the system without actually signing on (there was a thread
out here last week about doing this for a printer support
terminal).  At level 40 this is no longer allowed :(


The other major hole that QSECURITY Level 40 plugs is a
problem where (mostly MI) programs can illegaly aquire
authority though the misuse of pointers.  At Level 40 the MI
instructions that allow this are restricted from "user
Domain" programs (It's actually more involved than this, but
this is the quick explanation :).  At level 40 some third
party software may have a problem (Hawkeye is the only one
that I've seen recently that uses these unsanctioned
interfaces, and even they have a work around for it).  As
others have mentioned, you should turn on the Security Audit
Journal (QAUDJRN) to log any potential violations prior to
actually moving to QSECURITY level 40.  This can be done
easily with the CHGSECAUD command (it creates QAUDJRN and a
receiver, and handles receiver rolling for you).   You need
to montitor for *AUTFAIL and *PGMFAIL, but don't get fooled
into thinking that every authority fauailure entry (Journal
Type AF) is a level 40 violation.  You need only be
concerned with types B,C,D,J,R, & S.  My prediction is that
the number of these entries will be few.

Section 2.4 in the Security Reference Manual will give you
all the details you need.


HTH,

jte






--
John Earl                                          
johnearl@powertechgroup.com
The PowerTech Group                        206-575-0711
PowerLock Network Security              www.400security.com
The 400 School                               
www.400school.com
--
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.