Most notably, RACF “read access” means an FTP user can download, duplicate, and redistribute a dataset at will.
Standard RACF rules for dataset access determine whether a user can read a dataset. The original intention was to allow access to information related to the transaction at hand, typically while the user is under the control of a mainframe application. But with FTP, if users can read a file, they can copy it to their PCs and email it anywhere in the world with ease. Standard RACF rules for datasets do not consider that read access allows FTP sessions to offload whole files. Though there is some protection, it falls short of what is needed when FTP is added to the mix.
And FTP can do other risky things besides data transfer. With a standard FTP session, a client can snoop around the system for private information. A hacker might, for example, log onto FTP,
cd /u (change to the directory that often houses user’s workspaces), and list the contents–including several
userIDs (directory names associated with the user).
SITE command also allows for many dangerous operations. For example, with the
FILETYPE=JES, an FTP client can submit jobs to, and pull reports from, the JES queue.
SITE can also be used to change permission bits for a file, or to list detailed information about storage devices.
For these reasons, FTP functions need to be treated as protectable resources, just as datasets are. Although some basic protection mechanisms are in place, they don’t stand up to what is needed for a true enterprise-class secure protocol.
VitalSigns for FTP provides a link between z/OS FTP servers and z/OS security that will deny any specified users access to any specified FTP command.
Access can be as global or as specific as the administrator deems appropriate.