IBM Security Z Security

 View Only
  • 1.  ID(*) and PERMIT FROM

    Posted 3 days ago

    Greeting all,
    This question is about Command Verifier.
    I have implemented a profile of the form 'C4R.*.ACL.=STAR.*.**' in CLASS(XFACILIT).

    This is correctly preventing the specification of ID(*) in any PERMIT command.

    However, if a profile already exists with ID(*) specified (e.g. MYPROFILE2.*), then I can issue

    PERMIT 'MYPROFILE1.*' FROM('MYPROFILE2.*')

    and this succeeds in adding the ID(*) entry to the first profile.

    What options exits to control and restrict this behaviour?

    Many thanks

    Lennie



    ------------------------------
    Lennie Dymoke-Bradshaw
    Director
    Reverse Sweep Consulting Limited
    07504304158
    ------------------------------


  • 2.  RE: ID(*) and PERMIT FROM

    Posted 3 days ago
    Edited by Guus Bonnes 3 days ago

    There is an C4R.class.ACL.=FROM.profile policy profile that should prevent use of FROM. I agree that the equals sign (=) might be a bit confusing, but it is needed to avoid mixing FROM with a potential ID called FROM.

    Or, you could add ID(*) to the original ACL with access NONE, and thus prevent PERMIT FROM from changing the existing access level. (I didn't test/verify this, but it's supposed to work that way).

    ------------------------------
    Guus Bonnes
    ------------------------------



  • 3.  RE: ID(*) and PERMIT FROM

    Posted 3 days ago

    Guus,

     

    Thanks for that info. That's useful.

     

    What I think we need is a command that does all of the PERMIT ... FROM (...) actions but omits the ID(*) part. I guess I could write such a REXX routine using IRRXUTIL to read the from profile and generate PERMIT commands. The ID(*) would succeed or fail according to the CV controls. The performance hit of running the extra commands would not be a real problem given the relative rarity of the use of PERMIT   .....    FROM(....).

     

    Regards,
    Lennie

     






  • 4.  RE: ID(*) and PERMIT FROM

    Posted 9 hours ago

    An ugly solution might also be to issue a Post-Command based on the CLASS, and always issue a PE ID(*) DELETE. But that only works if you have no exceptions.

    Another possibility might be to add a System REXX as Post-Command, so that you can do some extra checking. Or implement your own suggestion as a Pre-Command System REXX.

    Or an RFE to enhance =PUBLIC to also include updates that make a profile public (in addition to affecting an existing public profile).



    ------------------------------
    Guus Bonnes
    ------------------------------