> > >we need a a lot of > > > new error messages to reflect that. > > > > Or just one: > > > > HCPnnnnE Command option not permitted by security profile. RC=1234 > > > Exactly what isn't permitted isn't the end user's business (to prevent > > gaming the system and determining what options are permitted by trial > > and error), but should be recorded in the ESM log. > > Beg to differ. My experience is that this is not helpful. My all time > favorite is the console log full of "Command complete for user" > messages. You want the requester and owner of the resource (the one > who can grant access) to be able to sort this out, so it should be > clear to either one of them which profile was preventing or not > allowing access. Hiding the why does not make it more secure. There > are more effective ways to detect systematic attacks and friends.
I think we will have to agree to disagree. Most of the security weasels I know claim that the less information you give a potential intruder, the better, but that stems from their mindset that *everyone* is a potential intruder. >From a usability standpoint, your argument has merit, but I think I would point out that much of the user context we've had historically no longer exists. The number of CMS-intensive shops is being slowly strangled to nothing, and we increasingly see CP plus guests, with only a tiny number of sysprogs having access to a CMS userid. At what point does the balance tip to focusing on the integrity of the CP hipervisors and guest OSes, not on CMS users? Also, if the question is determining what happened, what's to stop us from engineering a *standardized* way to determine the cause of a failure or to review the right set of logs, and deploying that. Right now, everyone out there has to build their own, and document it, and support it. The idea of a common security event stream with proper filtering is, oh, about 30-35 years old now. Isn't it time we caught up with the rest of civilization? > > > An easy API for > > > RACROUTE might be nice to avoid yet-another-list of powerful users > > > (especially since some weasels want that all disks with lists of > > > powerful users are protected against reading). > > > > Takes us back to either a universal *RPI service provider built into CP > > that we can connect to with pipes and do our own ESM, or supplying a > > default ESM that's more granular than the classic CP model, doesn't it? > > You're making wind and causing confusion. <sarcasm> Silly me. I thought I was having a serious discussion with other grownups about better ways to implement security models. Pardon me while I find the party in the other room. </sarcasm> > What I am asking for is an "application resource profile" that is not > used by CP but by applications to control access to services (e.g. > APPL.TCPIP.LINK.ABC could allow query or start/stop of link ABC based > on access to that profile). It would also require extra support in the > ESM to have granular access control for those 3rd party checks > (ICHCONN is global). And that's the next step. Once we can ask the questions and get answers at a granular level, then we go after the inconsistencies in CP command behavior, and extend to the parameter level; the syntax you propose looks nice, and would fit in with what I had in mind. > One could imagine a new/changed diagnose to ask CP to ask the ESM, but > we have no easy way to use such a diagnose. A new system IUCV service > looks cool but also lacks the tools to use it. So maybe a new CP > command is the easiest way. So you're proposing a *AUTH or something like that where you can pose a authorization question from a user, which will be answered by whatever is connected to *RPI? IUCV has the advantage that it can already be transported across ISFC, which would allow concentrating authorization information on certain nodes in a cluster, a useful scalability and auditability feature. -- db
