Date: Tue, 29 May 2001 13:21:45 +0100
Reply-To: Peter Crawford <peter.crawford@DB.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Peter Crawford <peter.crawford@DB.COM>
Subject: Re: Using a generic userid under RACF
Content-type: text/plain; charset=iso-8859-1
Hi Don, (mad)Michael, Colin, et al...
I have been shifting data across platforms quite a lot recently -
enough to wish/need to achieve this "in batch". With no user
interface, I need to hold these details in some safe way.
Generic userIDs look like a solution, only briefly.
Password security from os/390 outward (to some aix servers) is being
maintained(more or less) by holding ID and PWD in a "user-only" file.
On os390, this just means a file with userid prefix. The user can be
identified as the "owner" of the batch job - given by sas macro
variable &sysuid.
To keep things simple I put the ip address for the target server into the
main part of the filename and use ftp or rlink as suffixes.
The .rlink file is the connect script with hardcoded userid and password.
Where &ip is the macro var holding the ip a ddress (as a name), I give
these files names like &sysuid..&id..ftp or &sysuid..&ip..rlink
Any submitter of the batch processes needs create only these
private files holding userID and pwd for the other target servers.
I have not been as confident with the unix equivalent
= something like setting rights with chmod +600 ~/target.ip.adress.*
Hopefully there are not too many holes in this approach.
If you have warnings about security weaknesses in my approach, I would
be very pleased to hear from you via the list or privately,
Regards
Peter Crawford
Datum: 29/05/2001 11:46
An: SAS-L@listserv.uga.edu
Antwort an: don_stanley@xtra.co.nz
Betreff: Re: Using a generic userid under RACF
Nachrichtentext:
Not sure you interpreted the question right Michael. My interpretation is that
Colin wants a signon that the batch job he submits via FTP runs under, not just
the DB2 component of the job.
Either way, he's wrestling with a very similar issue to me at present. Ours is
SAS/CONNECT and security depts not wanting to permit us to use a generic signon
in an RLINK. I see the issue, anyone can see the userid and password. I did
exactly what Colin mentioned below, encrypted in a SAS dataset. That hasn't
placated them to any great extent, although they seem to have found useful
things to do and left me alone a bit since.
However the security guys point is valid, even if we encrypt the password in a
SAS dataset, somewhere there is code to de-encrypt and obtain that password, and
the exact same arguments apply, as in our place ultimately anyone can see that
code, be it in a public code library, or in SDSF or OMCS archives.
In my opinion, a bigger exposure is products like ConnectDirect and XCOM where
parameter files seem to demand that passwords are written for the world to see.
I collated a list of about 20 different signons and passwords that were publicly
available in parms files, just to show them the precedent existed -- I got the
impression it wasn't really appreciated :-)
To me, the security argument is valid. But I always have to ask, who is going to
bother searching archives and code for a password they don't know exists. Thats
pretty irrelevant though, the basic premise of security is that an exposure
should be removed.
If anyone does have answers, please post them to the group, its a question that
anyone using RLINK files should have an interest in.
Don
Michael Davis wrote:
> Hello Colin and other SAS-L friends,
>
> It took a re-read for me to figure out where you want to go with this. You
> want to set up passwords to DB2, not SAS. Also you probably need
> write-access to DB2 to use plan tables or similar structures.
>
> How about a touch of SAS/AF? Your SCL program would look something like:
>
> init:
>
> rc=libname('test', 'c:\test')
> ;
>
> rc=rc
> ;
>
> return ;
>
> In your case, you'd have to specify the DB2 as the engine and the password
> and SSID as options. The general syntax from the OnLine doc would be:
>
> sysrc=LIBNAME(libref<,SAS-data-library<,engine <,options>>>);
>
> How do you use it in your SAS program? Try PROC DISPLAY, which does *not*
> require SAS/AF on your mainframe.
>
> proc display c=work.sasltest.test.scl ; run ;
>
> where sasltest would be changed to the catalog that you put your SCL
> program into (test.scl here).
>
> When you run PROC DISPLAY, the log is going to look something like:
>
> NOTE: PROCEDURE DISPLAY used:
> real time 0.09 seconds
> cpu time 0.07 seconds
>
> There will be additional messages but the password will be masked on the
> SAS Log.
>
> If you compile the SCL so that the source code is not available, your
> security will be complete.
>
> - Michael "Mad Doggy" Davis
>
> At 10:02 PM 5/28/01 +1000, Colin Holmes <holmesc@ICA.NET.AU> wrote:
> >Hi SAS-Listers,
> >
> >we are running SAS V8.x on Windows NT and download DB2 data from the
> >mainframe (OS/390) via SAS/ACCESS.
> >To allow us to run jobs overnight we use a "generic" userid to be
> >authenticated by RACF. We would now like to submit jobs to JES2 via FTP,
> >however all jobs that are submitted run under the generic userid which has
> >limited access (i.e. read only).
> >
> >Before the system programmers / security departments will increase the
> >access permissions we need to ensure that the password
> >used by the generic userid is protected. Currently we have it encrypted in
> >a SAS dataset and use macros to build the libname and filename statements
> >which hold the password in a macro variable.
> >
> >Does anyone have any suggestions / recommendations for protecting the
> >password or a better solution to allow us to achieve the above ?
> >
> >TIA,
> >
> >Colin.
>
> Michael L. Davis
> Vice President
> Bassett Consulting Services, Inc.
> 10 Pleasant Drive
> North Haven CT 06473-3712
> E-Mail: michael@bassettconsulting.com
> Web: http://www.bassettconsulting.com
> Telephone: 203-562-0640
> Facsimile: 203-498-1414
> Messages: 888-477-1412
--
Don Stanley, B.SC, Dip O.R.S, MNZCS
EMAIL:: don_stanley@xtra.co.nz, don@sysware.co.nz
Author:: Beyond the obvious with SAS Screen Control Language.
Author:: Solutions for your GUI Applications Development Using SAS/AF FRAME
Technology
http://www.sysware.co.nz , http://www.geocities.com/don_stanley_nz/don_home.htm
--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
