Re: Password "Hint" Feasibility

Hi John,

Thanks for clearing that up. My problem is I have no system. I cannot create
a user profile on my client's machines. I cannot do it on my timeshare
account. The last time I had a client where I was authorized to do this was
before FTP was a household word. However, I do have a new client where I may
have to be concerned with security, but since it's very small (model 150)
with a very limited application, all such access methods may not even be in
use. But I may get to play around with them.

Regards,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax

----- Original Message -----
From: "John Earl" <johnearl@400security.com>
To: <MIDRANGE-L@midrange.com>
Sent: Monday, November 13, 2000 6:09 PM
Subject: Re: Password "Hint" Feasibility


> 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
> +---

+---
| 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
+---