Re: BPX.SMF misuse?

[Charles Mills]

Some "user" records are not really "user" records.

ACF2 writes type 230 records. Top Secret writes type 231 records. Our IND$FILE 
auditing writes type 202 records. (All are configurable default record numbers.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Tuesday, May 31, 2016 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPX.SMF misuse?

On 01/06/2016 01:54 AM, Lindy Mayfield wrote:
> If you try to call BPX1SMF with an SMF record number of 128 or less you'll 
> get a return code 121, EINVAL.  So only user SMF records are allowed.
>
That's not as bad as I thought then, but most sites would consider user SMF 
records as important.

Interesting... JZOS writes type 121, and I thought it wasn't writing records 
without access to BPX.SMF... maybe I need to retest and confirm.

Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Andrew Rowley]

On 01/06/2016 12:25 AM, Andy Higgins wrote:

Does OA48775 provide this?

http://publibz.boulder.ibm.com/zoslib/pdf/OA48775.pdf


It does look like a step in the right direction, that I was unaware of.

Reading the fine print, it requires a "clean program-controlled 
environment". I'm not sure whether that allows e.g. writing the JZOS 
records, particularly if you had any JNI code. Without the clean 
environment you need access to the basic BPX.SMF.


It's still not a complete solution though. I think it's important to be 
able to identify the writer of the SMF record, so ideally you would have 
an interface that wrapped untrusted information into a new SMF record 
that included a header identifying the origin userid and address space. 
That way, if you had something writing bad records it would be 
relatively easy to identify and exclude them.


The JZOS records look very useful, but I'm not sure whether the security 
issue means that sites should not normally be using them.


Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Andrew Rowley]

On 01/06/2016 01:54 AM, Lindy Mayfield wrote:

If you try to call BPX1SMF with an SMF record number of 128 or less you'll get 
a return code 121, EINVAL.  So only user SMF records are allowed.

That's not as bad as I thought then, but most sites would consider user 
SMF records as important.


Interesting... JZOS writes type 121, and I thought it wasn't writing 
records without access to BPX.SMF... maybe I need to retest and confirm.


Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Lindy Mayfield]

If you try to call BPX1SMF with an SMF record number of 128 or less you'll get 
a return code 121, EINVAL.  So only user SMF records are allowed.

Br,
Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: tiistaina 31. toukokuuta 2016 9.34
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: BPX.SMF misuse?

My main point however was that if you need BPX.SMF access to write JZOS 
statistics, you can also write any data into any SMF record type you like, 
including writing your own type 30, type 80, type 89...

--
Andrew Rowley
Black Hill Software
+61 413 302 386


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Kirk Wolf]

Seems to.  I wasn't aware that this was available.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, May 31, 2016 at 9:25 AM, Andy Higgins 
wrote:

> On Tue, 31 May 2016 08:39:04 -0500, Kirk Wolf  wrote:
>
> >I agree with the OP's suggestion that there should be fine grained control
> >to allow unauthorized jobs to write certain types of SMF records.
> >
> >Perhaps a BPX.SMF.TYPxx resource?
> >
> >Kirk Wolf
> >Dovetailed Technologies
> >http://dovetail.com
> >
>
> Does OA48775 provide this?
>
> http://publibz.boulder.ibm.com/zoslib/pdf/OA48775.pdf
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Andy Higgins]

On Tue, 31 May 2016 08:39:04 -0500, Kirk Wolf  wrote:

>I agree with the OP's suggestion that there should be fine grained control
>to allow unauthorized jobs to write certain types of SMF records.
>
>Perhaps a BPX.SMF.TYPxx resource?
>
>Kirk Wolf
>Dovetailed Technologies
>http://dovetail.com
>

Does OA48775 provide this?

http://publibz.boulder.ibm.com/zoslib/pdf/OA48775.pdf

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Kirk Wolf]

I agree with the OP's suggestion that there should be fine grained control
to allow unauthorized jobs to write certain types of SMF records.

Perhaps a BPX.SMF.TYPxx resource?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, May 31, 2016 at 1:33 AM, Andrew Rowley  wrote:

> On 31/05/2016 16:14, Martin Packer wrote:
>
>> On the "add Java statistics to the SMF record" point note NOTHING gets to
>> inject stuff into SMF 30.
>>
>
> I'm not suggesting that Java itself inject anything into SMF 30, the
> thought was that the JVM could keep statistics in some system area that was
> then incorporated in a new section in the SMF 30 record, i.e. similar to
> the Unix Process Section or Counter Data Section. But it's probably true
> that Java statistics are too specific for a general record like type 30.
>
> My main point however was that if you need BPX.SMF access to write JZOS
> statistics, you can also write any data into any SMF record type you like,
> including writing your own type 30, type 80, type 89...
>
>
> --
> Andrew Rowley
> Black Hill Software
> +61 413 302 386
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Andrew Rowley]

On 31/05/2016 16:14, Martin Packer wrote:

On the "add Java statistics to the SMF record" point note NOTHING gets to
inject stuff into SMF 30.


I'm not suggesting that Java itself inject anything into SMF 30, the 
thought was that the JVM could keep statistics in some system area that 
was then incorporated in a new section in the SMF 30 record, i.e. 
similar to the Unix Process Section or Counter Data Section. But it's 
probably true that Java statistics are too specific for a general record 
like type 30.


My main point however was that if you need BPX.SMF access to write JZOS 
statistics, you can also write any data into any SMF record type you 
like, including writing your own type 30, type 80, type 89...


--
Andrew Rowley
Black Hill Software
+61 413 302 386


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[Martin Packer]

On the "add Java statistics to the SMF record" point note NOTHING gets to
inject stuff into SMF 30.

The one arguable exception to this is the Usage Data Section, but this is
for licencing.

Right now Java doesn't use the IFAUSAGE macro. Perhaps it could be taught
to. If so maybe A VERY FEW statistics could be collected that way.

Cheers, Martin

Sent from my iPad

> On 31 May 2016, at 02:17, Andrew Rowley 
wrote:
>
> I just discovered that JZOS can now write Java statistics to SMF - nice!
>
> But... it looks like it requires users to have access to BPX.SMF to
> write the record - not so nice. If I understand correctly, access means
> you can write any type of record with any sort of garbage to SMF - not
> what you need for an audit trail.
>
> I think Co:Z SFTP also creates SMF records that require everyone to have
> access to BPX.SMF. BPX.SMF is supposed to be for server address space
> userids, but it seems like it is being used as a shortcut to bypass
> designing a proper way of cutting SMF records. I don't think that this
> is a good thing. It is even worse that it is IBM shipping features
> (JZOS) that encourage you to disable the security. (They don't tell you
> to do it, but if it doesn't work if you don't...)
>
> Maybe what is required is an official interface for untrusted tasks to
> write data to SMF?
>
> Something along the lines of:
>
> * A single SMF record type for all untrusted data
>
> * The interface adds a header that identifies the user & job that wrote
> the record, plus some sort of key to identify the user record type
>
> * RACF control over who can write records with specific keys - even
> better if you can control which programs can write the records
>
> * User data supplied is appended after the system generated header
>
> On the Java side, it would be nice if Java statistics were added to the
> type 30 records. I assume the JVM already has various functions that
> require authorization, so it shouldn't be too much of a stretch to keep
> the statistics somewhere that they could be included in the type 30.
> Much better than writing them from userland in JZOS.
>
> Andrew Rowley
>
> --
> Andrew Rowley
> Black Hill Software
> +61 413 302 386
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: BPX.SMF misuse?

[David Crayford]

JZOS is just a thin JNI wrapper over the C/C++ runtime __smf_record() 
function 
https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.bpxbd00/rsmfre.htm. 
The same rules apply.


On 31/05/2016 9:16 AM, Andrew Rowley wrote:

I just discovered that JZOS can now write Java statistics to SMF - nice!

But... it looks like it requires users to have access to BPX.SMF to 
write the record - not so nice. If I understand correctly, access 
means you can write any type of record with any sort of garbage to SMF 
- not what you need for an audit trail.


I think Co:Z SFTP also creates SMF records that require everyone to 
have access to BPX.SMF. BPX.SMF is supposed to be for server address 
space userids, but it seems like it is being used as a shortcut to 
bypass designing a proper way of cutting SMF records. I don't think 
that this is a good thing. It is even worse that it is IBM shipping 
features (JZOS) that encourage you to disable the security. (They 
don't tell you to do it, but if it doesn't work if you don't...)


Maybe what is required is an official interface for untrusted tasks to 
write data to SMF?


Something along the lines of:

* A single SMF record type for all untrusted data

* The interface adds a header that identifies the user & job that 
wrote the record, plus some sort of key to identify the user record type


* RACF control over who can write records with specific keys - even 
better if you can control which programs can write the records


* User data supplied is appended after the system generated header

On the Java side, it would be nice if Java statistics were added to 
the type 30 records. I assume the JVM already has various functions 
that require authorization, so it shouldn't be too much of a stretch 
to keep the statistics somewhere that they could be included in the 
type 30. Much better than writing them from userland in JZOS.


Andrew Rowley



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

BPX.SMF misuse?

[Andrew Rowley]

I just discovered that JZOS can now write Java statistics to SMF - nice!

But... it looks like it requires users to have access to BPX.SMF to 
write the record - not so nice. If I understand correctly, access means 
you can write any type of record with any sort of garbage to SMF - not 
what you need for an audit trail.


I think Co:Z SFTP also creates SMF records that require everyone to have 
access to BPX.SMF. BPX.SMF is supposed to be for server address space 
userids, but it seems like it is being used as a shortcut to bypass 
designing a proper way of cutting SMF records. I don't think that this 
is a good thing. It is even worse that it is IBM shipping features 
(JZOS) that encourage you to disable the security. (They don't tell you 
to do it, but if it doesn't work if you don't...)


Maybe what is required is an official interface for untrusted tasks to 
write data to SMF?


Something along the lines of:

* A single SMF record type for all untrusted data

* The interface adds a header that identifies the user & job that wrote 
the record, plus some sort of key to identify the user record type


* RACF control over who can write records with specific keys - even 
better if you can control which programs can write the records


* User data supplied is appended after the system generated header

On the Java side, it would be nice if Java statistics were added to the 
type 30 records. I assume the JVM already has various functions that 
require authorization, so it shouldn't be too much of a stretch to keep 
the statistics somewhere that they could be included in the type 30. 
Much better than writing them from userland in JZOS.


Andrew Rowley

--
Andrew Rowley
Black Hill Software
+61 413 302 386


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN