Rick Fochtman wrote:
-----------------------<snip>-----------------
From time to time I read on the list about companies which demand ISVs
to provide source code for SVC routines to analyze it from security
point of view.
While I don't know to much about z/OS 'guts', I'm wondering what is
the reason for that? Or rather, why the SVC code is so important,
while APF-authorized libraries are not subject to analyze. The same
apply to propgrams in SCHEDxx members.
AFAIK (I could be wrong) APF-authorized program can bypass security
rules, so it can be dangeours. Is SVC more dangerous ?
Last, but not least - neither SVC, nor 'regular' APF-authorized
program can do anything illegal when not instructed, so unless ISV
folks unlimited access to prod system it is like dangerous knife in my
safe.
Other possibility is that "backdoor" entry is disclosed by ISV to our
sysprogs. In fact it owuld be a confession to security hole.
---------------------<unsnip>----------------------
My last shop processed enough money in a week to pay the U. S. National
Debt, and NONE of that money was ours. We had to be like Caesar's wife,
Calpurnia. That is, not only be pure, but perceived to be pure by all
who beheld us. Security was held to be far more important than
performance by "The Powers That Be".
IMHO it is completely irrelevant. Almost every z/OS installation process
'non-ours' money, usually much more than sysprog's salary. <what a
pity!> So, all shops care about security, more or less.
Caution: I don't criticise SVC examination itself. I don't want to say
it os good or it is bad. I just want to learn. My doubt is why SVC are
so suspected while APF-authorized programs are not. It's common
knowledge that sysprog+APF means bypass all security rules - isn't it ?
To Wayne Driscoll:
Thank you for detailed explanation. Actually I'm aware on APF nuances,
like AC(1), concatenation of APF and non-APF code, invoking lnklst
programs as APF-authorized.
My fault, I didn't expressed it clearly: I meant "direct invokation" as
simly running a job with PGM=apfprog. This is what I meant as "direct".
BTW: Is it better description for the above ?
BTW: My understanding of 'SVC risk' vs 'APF risk'
- both can do dangerous things.
- SVC can be invoked by non-authorized program and then could provide
'wide-open' security hole. Open to everyone who know how to invoke it.
No additional privilege is checked.
- APF code invoked directly (PGM=apfmodule) could do anything, but the
'anything' have to be coded inside the program.
- APF programs, when do something considered as security bypass (i.e.
DSS DUMP ADMIN) usually check for authority of the caller i.e.
STGADMIN.ADR.STGADMIN.DUMP.xxx
THatnk you for clarification.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
