On 1 December 2013 20:47, Jim Thomas <j...@thethomasresidence.us> wrote: > That said, AFAIK, there's really not much, save but for a RACROUTE > REQUEST=AUTH perhaps, that I could do in terms of validation, I could do. > Then again, even w/a RACROUTE/AUTH, it > still does not guarantee integrity. > All the above does is to make things a little harder for inappropriate > users. Perhaps that is all we can do ??.
One should be able to do better than making it a little harder; it should be very hard indeed. Part of this is carefully thinking through the authorization model. You mention RACROUTE REQUEST=AUTH, and that may well be a good start. But you need to be clear in your mind about what sort of entity you are authorizing to do what action(s). A RACF userid generally represents a real person, but it may also represent a department (e.g. operations), or various other non-person things. A hard-line view says that there should be a one-to-one mapping of people to userids, but both a principled view and common practice make that unlikely to be what you encounter everywhere. So will your RACROUTE authorize a person to run your magic code, or will it authorize the calling code to do something, or...? Is there a Trojan horse attack in there somewhere, for example can an unauthorized person convince an authorized one to run something from an inappropriate library? These are some quick thoughts; as well as good coding practices you need an authorization model (i.e. how the the good guys will be determined), and a threat model for how the notional bad guys will subvert your authorization process. The documentation surrounding IBM's original MVS statement of system integrity from the early 1970s remains to this day a remarkably current taxonomy of threats and failures, and it avoids listing what Schneier much later called "movie plot threats" in favour of categorizing them in a way that can be defended against. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
