BPX.SMF...: Just a question

Discussion of Co:Z sftp, a port of OpenSSH sftp for z/OS
Post Reply
Shady
Posts: 37
Joined: Wed Feb 24, 2010 10:50 pm

BPX.SMF...: Just a question

Post by Shady »

Hi....

are there plans to change the way Co:Z SFTP cuts SMF records, so that not every user nead READ to BPX.SMF? That's the main problem we still have....
Maybe with APF authorization like SSHD has? Because you wrote here:
dovetail wrote:Another *very* interesting change is that IBM's version of sftp and sftp-server are shipped APF authorized.
Click me
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Post by dovetail »

Background: The system service for recording an SMF record requires APF authorization. We chose to use the BPX1SMF (__smf_record()) library call, which doesn't require APF authorization but does require READ access to BPX.SMF.

We believe that most customers will prefer to grant READ to BPX.SMF rather than to run Co:Z sftp-server as APF authorized. It is apparently one thing for IBM to ship code APF authorized, but for us to do it is something else :-)

We would appreciated any feedback from users on this point; please post your opinion as a response to this thread.

We would consider an enhancement so that IF a customer wanted to run APF authorized, THEN READ access to BPX.SMF would not be required. But if we did this, any security exposures would be the customer's responsibility. If this is something that you are interested in, please send me an email offline to info@dovetail.com.

BTW: we do ship a sample script that can be used to relink sftp-server with AC=1 and to mark it APF authorized. This was done for a customer that had exits that needed to run APF authorized.

There is another possibility - Co:Z sftp and sftp-server support a network management interface whereby SMF records can be received in real-time by another job/program. This NMI uses a Unix-domain datagram socket to receive SMF records from any sftp or sftp-server job. One option would be to grant this job BPX.SMF access and delegate SMF recording to it. This would require, however, that a job be running all of the time to run this program.
Shady
Posts: 37
Joined: Wed Feb 24, 2010 10:50 pm

Post by Shady »

dovetail wrote:We would appreciated any feedback from users on this point; please post your opinion as a response to this thread.
We discussed in the group.
We think it would be an good alternative with APF authorization. The point is...: We have to give everybody READ to BPX.SMF. What happen if somebody haven't access? There won't be SMF records cut. That could be a problem for the audit.

The third possibility with a programm that receive SMF and write would be a nice thing. But we have to write it for ourselves, right...?

OK... for the other stuff you wanted a email...
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Re: BPX.SMF...: Just a question

Post by dovetail »

Following up on this -

In Co:Z release 1.10.0, we added a sample program "CoZSmfServer" which demonstrates how SMF records may be received in real time from Co:Z client and server. See the documentation and build instructions in $COZ_HOME/samples/smfapi/CoZSmfServer.C

With this program, you can disable recording SMF in the actual Co:Z SFTP client or server jobs (by configuring a system-wide "nosmf" option), and then run a separate job that receives SMF records in real time over a Unix datagram socket. The sample program then writes the SMF records, so only the userid running this job will need "BPX.SMF" authority.
Post Reply