Re: Password "Hint" Feasibility

[John Earl <johnearl@xxxxxxxxxxxxxxx>]

Peter,

Peter Dow wrote:

> Hi John,
>
> I was going to ask which solution you thought best, and just saw it pop up
> before I sent this. I still have the following question:
>
> How difficult is it to lock down a single user profile to a single program?
> An initial signon program, limited capability user, no message queue break
> handling program, no group authority, no attention program, sign off at
> program end, etc. etc. -- what would they be able to do with their *PUBLIC
> authority? This is not a rhetorical question, I'd really like to know.

To answer your own question, take a look at your system and see which objects
*PUBLIC has *USE authority to.  Those are all of the objects that "HINT" would 
be
able to read and/or execute.  Then take a look at all of the data files that
*PUBLIC has *CHANGE authoroity to.  Those are the data files that "HINT" could
read and/or change the contents of.  IF *PUBLIC has *ALL authority to any file,
"HINT" would be able to CLRPFM or even delete the file.

Unfortunately, OS/400 is shipped with the SYSVAL QCRTAUT set to *CHANGE, so
unless you've tightedned things down, all new objects are created with
*PUBLIC=*CHANGE.

The following passage....

> An initial signon program, limited capability user, no message queue break
>   handling program, no group authority, no attention program, sign off at
>   program end, etc. etc
>
Indicates that you have done a thorough job of securing access through 5250
interfaces, but the point I continually try to make here (I'm sure that there 
are
others besides me who are tired of hearing me say it :(      ) is that FTP, 
ODBC,
DDM, Client Access File Transfer, etc. etc. etc. are all ways of getting at your
data without respect to any of your 5250 security precautions.  (In fairness, 
yes
we sell Exit Programs tha block this sort of access, and I'm sure folks are 
tired
of hearing that line as well).  The precautions that you've written about only
protect your data from users who sign on via an AS/400 signon screen.  If the
user doesn't use the signon screen, those precautions can't protect you.

To demonstrate my point, create a user profile called HINT (with a secret
password!) that does not belong to any group, has no special authority, is
limited capability, and what the heck, give it an initial menu of *NONE and an
initial program of *NONE so that it isn't even allowed to access via the green
screen.  Now use that profile to signon with FTP, ODBC, Client Access, etc. and
see what it has access to.  I think you will be shocked.  Anything that *PUBLIC
has appropriate (or should I say inappropriate!) access to, "HINT" will be able
to read, change, clear, or delete.


[For the uninitiated, here's an excerpt on an FTP test that we host on our
website....
1) Open a DOS window on your PC.
2) At the C:\WINDOWS prompt type "FTP as400name" or "FTP nnn.nnn.nnn.nnn"
     (Quotes not required)
3) The system will prompt you to signon. Sign on as any valid AS/400 user.
4) To see all of the objects in your current library, use the DOS "dir" command
to display the contents of the library.
5) Type the FTP "get" command to download any file you have object level
authority to
      Example: "get qgpl/qddssrc.qdsignon c:\qdsignon.txt"
      If you open c:\qdsignon.txt with notepad you'll see the DDS source on your
PC
6) Then use the FTP "put" command to upload a file to the AS/400
      Example: "put c:\autoexec.bat qgpl/customer
      DSPPFM qgpl/customer and you'll see your autoexec.bat on the AS/400
Theres much more to it,but that should give you a flavor]

In summary, *PUBLIC has too much authority, and there are too many ways to 
access
your data that are unaware of any 5250 menu controls that are in place.  (There
was an "ODBC Security" thread just last week that outlines the danger one
sysadmin saw with *PUBLIC's access through ODBC...)  Don't rely menu security, 
it
can't be trusted.  And don't create generic user ID's.  They can be used to
access your system with *PUBLIC's authority.  And investigate exit programs,
because if you're relying on the 5250 controls, I'd bet that your legitimate end
users have too much authority (using FTP, ODBC, etc.) to your data already.

hth,

jte


--
John Earl                    johnearl@400security.com
The PowerTech Group      --> new number --> 253-872-7788
PowerLock Network Security   www.400security.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
+---