Re: Ops privs
The need to do an IUCV connection adds a lot of complexity we don't need. As complexes of systems get larger, then depending on synchronizing local caches of authorization information becomes a (n**2-1) problem. You also need a level of abstraction -- given the demo of VMPlex that has been shown at SHARE and elsewhere, there will need to be arbitration of who answers the question in a multimode complex if we are to get a true single-system image. I think that if we want even locally written tools to exploit this, a CP command would be better. Even if that means it becomes a synchronous interface. So CP CANYOUDO resource name access mode I think the user-space presentation is orthogonal to the internal function. Internally, the command could contact an authorization service, which may be on the local node or elsewhere in the cluster if the admin so chooses. You could permit caching for speed, although that could get complicated in terms of rule expiration or changes in authorization profiles during a login session. What about: CP TEST resource operation RC=0 if operation permitted, RC=28 if not permitted, RC=some high number if there was an error getting an answer. 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. I think it would be enough to get CP's answer on *this* system, whatever way CP has come to that conclusion. If CP would trust to connect to the ESM via ISFC, then CP may use that... Hmm. What about a hybrid model: if CP joins an ISFC cluster, part of the cluster initialization exchange could include the presence or absence of a central authorization service. If present, each CP could connect and notify the service of its presence and a IUCV node and target to connect to. The authorization service (wherever it resided) could then connect back to the supplied target and populate a local cache of authorization rules. In this scenario, if you had a central authorization system, you could supply a timeout for each entry or push updates at any time (assuming that CP sorted the cache by freshness of an entry). At or near expiration of an entry, that node could contact the auth service and slurp down a fresh set of rules into a separate table, then flip over to the new set for minimal exposure to a no rule for that setup. You could then create a DIAG to validate a test against the local authorization cache -- which would be easy to use to implement the local CP command you suggested, but also allow the scale-up I'm looking for.
Re: Ops privs
This is just what I would say (except for VM:Secure rather than RACF). Shimon I want to wind back a bit on this one:- We do use RACF as an ESM and we do use LOGONBY (controlled by RACF profiles) extensively. I understand that any user with LOGONBY authority can log on and give any of the commands mentioned but we would be extremely unhappy about these users being able to give those commands on behalf of that user without logging on. This should not be the assumption and, if it becomes so, then there should be an easy way to revert to the current status :- There are 2 issues here :- 1. Visibility Searching RACF audit record is no substitute for seeing the commands entered on the console of the user. 2. Serialisation Insisting the user logs on (LOGONBY) ensures that they (and only they) have control of that user at that time.\ I would be OK with the ability to enable the behaviour suggested but I would be very unhappy for it to be the default that we had to find a workaround for. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com -- Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Ops privs
Late to the party (I must have been in the other room that David was searching for), but adding on to Colin's reply below: I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority We wrote a mod to CP to prevent users with PRIVCLAS 'N' from completing LOGOFF as expected, the CP mod changes the LOGOFF to DISCONNECT. VTAM, GCS, and select other svms have been assigned class 'N' here (after experiencing accidental and undesirable LOGOFF of those svms by errant sysprogs of many backgrounds). I empathize with Alan's original intention: making it easier to manage userids that you have access to logon anyway. But as the short guy with the big ears (no not Mickey Mouse or George W Bush; Ross Perot) once said: The devil's in the details. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Colin Allinson [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/27/2007 11:54 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Ops privs Alan Altmark [EMAIL PROTECTED] wrote(in part) :- I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: Most CP commands right now only allow the ESM to audit, not to control access. If the ESM gets granular access control, we need a a lot of new error messages to reflect that. Or just one: HCPE 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. 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. *RPI is what CP uses to connect to the RACFVM's. CMS Pipelines can connect to *RPI but that's the reverse of what we want. 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). 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. Rob
Re: Ops privs
I want to wind back a bit on this one:- We do use RACF as an ESM and we do use LOGONBY (controlled by RACF profiles) extensively. I understand that any user with LOGONBY authority can log on and give any of the commands mentioned but we would be extremely unhappy about these users being able to give those commands on behalf of that user without logging on. This should not be the assumption and, if it becomes so, then there should be an easy way to revert to the current status :- There are 2 issues here :- 1. Visibility Searching RACF audit record is no substitute for seeing the commands entered on the console of the user. 2. Serialisation Insisting the user logs on (LOGONBY) ensures that they (and only they) have control of that user at that time.\ I would be OK with the ability to enable the behaviour suggested but I would be very unhappy for it to be the default that we had to find a workaround for. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Ops privs
This is the kind of change that I hope WILL NOT be the default and will actually take some effort on my part to implement. It is too dramatic a change, with too many installations depending upon the current behavior. As to the serialization of control of a target user, what if there were a 'lock' setting that could be set before executing these new commands on behalf of a target user and unset when the administrator is finished fiddling with the target user. If done in an ESM, I would hope that rules could be written to require that the 'lock' be set by the same requestor. /Tom Kern /301-903-2211 --- Colin Allinson [EMAIL PROTECTED] wrote: I want to wind back a bit on this one:- We do use RACF as an ESM and we do use LOGONBY (controlled by RACF profiles) extensively. I understand that any user with LOGONBY authority can log on and give any of the commands mentioned but we would be extremely unhappy about these users being able to give those commands on behalf of that user without logging on. This should not be the assumption and, if it becomes so, then there should be an easy way to revert to the current status :- There are 2 issues here :- 1. Visibility Searching RACF audit record is no substitute for seeing the commands entered on the console of the user. 2. Serialisation Insisting the user logs on (LOGONBY) ensures that they (and only they) have control of that user at that time.\ I would be OK with the ability to enable the behaviour suggested but I would be very unhappy for it to be the default that we had to find a workaround for. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433
Re: Ops privs
We use LOGONBY to be able to log onto a test user whose profile has nothing but class G authority. It's great to be able to do final testing to make sure that the final users have access to all necessary functions. Changing the privileges by default might negate some of those results. Nora Graves [EMAIL PROTECTED] Main IRS, Room 6513 (202) 622-6735 Fax (202) 622-3123 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 24, 2007 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts?
Re: Ops privs
On 8/27/07, Graves Nora E [EMAIL PROTECTED] wrote: We use LOGONBY to be able to log onto a test user whose profile has nothing but class G authority. It's great to be able to do final testing to make sure that the final users have access to all necessary functions. Changing the privileges by default might negate some of those results. I think your scenario would still be safe with what Alan suggested. During your test you would have the privileges of the target only. Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. Rob
Re: Ops privs
I also agree with Richard. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Friday, August 24, 2007 6:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs I agree with Richard. Not only do you have a serialization issue with multiple people able to issue commands, but all these additional commands would need to be logable by an ESM. I can't think of any cases where I'd want to give SEND or SIGNAL SHUTDOWN authorization to general users. If I did, I'd rather be able to give that authorization individually, and not have it lumped in with Logonby. Dennis O'Brien _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, August 24, 2007 13:21 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Ops privs No. No. No. No. No. We use LOGONBY as a means of controlling who is allowed to log on to group ids and tracking what they do. None of those other commands would be useful or necessary in that context. Giving those permissions would negate, or at least complicate, our ability to track who did what when. Further, we would not want one user to be able to alter or compromise the functions being performed by another who was already logged on via LOGONBY. SEND, FORCE, and SIGNAL SHUTDOWN certainly have that potential, for example. Most of what is listed could be useful only to someone who is really knowledgeable about the functions of the virtual machine. They are also mostly useful in looking after service machines. They are not useful to someone who is a more naïve user who logs on to a group id to perform simple functions or to run an application program, and could be somewhat dangerous if abused, accidentally or on purpose, by such a person. It is the latter group that we must protect against by not giving them authorities that they will never need. The former group probably has the knowledge needed to function without the added authority. Regards, Richard Schuh _ There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
we need a a lot of new error messages to reflect that. Or just one: HCPE 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
Re: Ops privs
If it were done in that other ESM for VM, it would be in its audit file. In the absense of an ESM to inplement it, it would be BAU with no new capability. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Saturday, August 25, 2007 5:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sat, 25 Aug 2007 00:20:38 +0200 Rob van der Heij said: On 8/24/07, Alan Altmark [EMAIL PROTECTED] wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Put away what you're smoking... Let's get back again to the style where we come up with the requirements and plea for years to get the commands in the directory, and you guys code it ... :-) I understand the idea that these commands achieve things that you could do if you would logon to the virtual machine. Sure, but far from complete: FOR has been suggested, but what about STORE HOST (as long as the frame holds a page of that virtual machine) and DETACH, and... My major concern is auditing. While I trust that the implementation will take care of auditing in the ESM, it makes it much harder to see who has been messing with it. Normally when a user tells his server suddenly failed you could scan the PROP logging and see which of the developers reconnected, and tell him to hit his peer over the head with it. But when neither of the virtual machines has its console spooled, you would not be able to tell what happened. Well, that implies a greater need for logging the auditing. The other system does that via SMF. In VM, that would be either Accounting records or Monitor records. Based on granularity of controlling how much is logged, and the similarity of what is done for other logging uses on VM, I'd recommend Monitor records. ... Rob /ahw
Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: 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? The need to do an IUCV connection adds a lot of complexity we don't need. I think that if we want even locally written tools to exploit this, a CP command would be better. Even if that means it becomes a synchronous interface. So CP CANYOUDO resource name access mode 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. I think it would be enough to get CP's answer on *this* system, whatever way CP has come to that conclusion. If CP would trust to connect to the ESM via ISFC, then CP may use that... Rob
Re: Ops privs
On Monday, 08/27/2007 at 09:20 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). Rob, I did not propose to give TESTABC the authorization that TCPMAINT would have/ Rather, I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. That is only the default RACF implementation and is controlled by a RACF exit; CP does not redrive the authorization. In fact, the Common Criteria evaluated configuration requires that this exit be removed. It's on the To Do list to allow the RACF admin to identify specific users who are, in fact, batch machines that need that functionality. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Alan Altmark [EMAIL PROTECTED] wrote(in part) :- I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :- 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? Overall you may be right but we are not the only TPF shop where there are many hundreds of VM userids running TPF and many more for the control and administration of these. It will be a long while before we reach the simplicity of running 20-30 Linux images where everything is done within the guests. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Ops privs
But isn't FORCE just shorthand for LOGON u1 HERE By u2 followed by LOGOFF? Bob Bolch I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :-
Re: Ops privs
David Boyes [EMAIL PROTECTED] wrote :- 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? Overall you may be right but we are not the only TPF shop where there are many hundreds of VM userids running TPF and many more for the control and administration of these. It will be a long while before we reach the simplicity of running 20-30 Linux images where everything is done within the guests. Makes sense, and there will always be exceptions, just as the guest-only configuration was the exception a few years back. I don't want to prohibit your configuration, but I do want to try to get the default configuration to reflect the most common uses (principle of least surprise).
Re: Ops privs
That way, you can surprise everyone who has been using the old defaults for years :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Monday, August 27, 2007 10:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs I don't want to prohibit your configuration, but I do want to try to get the default configuration to reflect the most common uses (principle of least surprise).
Re: Ops privs
It depends. There is the BYUSER field that gets updates with the LOGON ... BY u2. Would it get updated by the FORCE? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Bolch Sent: Monday, August 27, 2007 10:08 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs But isn't FORCE just shorthand for LOGON u1 HERE By u2 followed by LOGOFF? Bob Bolch I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :-
Re: Ops privs
Reminds me of a system modification we had back in the day, at another company, that the SNA Staff could LOGON to VMVTAM but could not issue LOGOFF. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 09:20 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). Rob, I did not propose to give TESTABC the authorization that TCPMAINT would have/ Rather, I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. That is only the default RACF implementation and is controlled by a RACF exit; CP does not redrive the authorization. In fact, the Common Criteria evaluated configuration requires that this exit be removed. It's on the To Do list to allow the RACF admin to identify specific users who are, in fact, batch machines that need that functionality. Alan Altmark z/VM Development IBM Endicott This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
On Monday, 08/27/2007 at 12:55 EDT, Colin Allinson [EMAIL PROTECTED] wrote: I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. I hear you. I have understood from the various comments like yours that the concerns are not actually related to security, but to system management (avoiding accidents). I understand and accept that. So, no worries about users suddenly and unexpectedly being able to FORCE (e.g.) another user. You will still need to be aware of CP FOR's use of LOGON BY as authorization (ESM only, and only when you are not currently the secuser). Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Is FOR new with 5.3? H CP FOR gets me the display for FOrward. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 12:55 EDT, Colin Allinson [EMAIL PROTECTED] wrote: I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. I hear you. I have understood from the various comments like yours that the concerns are not actually related to security, but to system management (avoiding accidents). I understand and accept that. So, no worries about users suddenly and unexpectedly being able to FORCE (e.g.) another user. You will still need to be aware of CP FOR's use of LOGON BY as authorization (ESM only, and only when you are not currently the secuser). Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On Monday, 08/27/2007 at 02:17 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Is FOR new with 5.3? H CP FOR gets me the display for FOrward. Yes, it is new with z/VM 5.3. And the abbreviation of FORWARD is now FORW. :-) Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: 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. More like different context. For *authentication* it is good practice not to reveal any information when wrong credentials are supplied. This is where the weasels come from. It was just a nasty prank of me to do a password check that provided hits like 4 good, 2 at the wrong place or the next password response. The approach to revoke a user when someone tried to logon to that account 3 times with a wrong password is imho more a security problem than a solution to one. But once the user is authenticated, it's not a potential intruder anymore. At that point, we normally assume the user is doing the right thing because business conduct guidelines will guide the user. If such a relation does not exist, you have entirely different problems that don't get solved by a computer says No response (see my Less that G approach). Rob
Re: Ops privs
On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Better the evil you know then the one you do not know? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 3:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On Aug 27, 2007, at 2:53 PM, Alan Altmark wrote: On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam
Re: Ops privs
I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
Alan, Hi. My name really is Bob and I'm a z/OS sysprog. pause for greeting And I am looking for a new job! :-) Seriously, as of last week, I have been informed that my position has been eliminated. If anyone on this list is looking for an individual with basic z/VM and Linux skills coupled with extensive z/OS skills, please drop me a note offline. My apologies to the list administrator for not clearing this blatant attempt for assistance in my job search in advance of posting it. Bob Richards VP, Enterprise Technologist - - Enterprise Technology Infrastructure- - Mainframe Services Capacity Performance Mgmt - - Office: 404-575-2798Mobile: 610-246-2943 - - email: [EMAIL PROTECTED] - -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 3:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] Alan Altmark z/VM Development IBM Endicott LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL]
Re: Ops privs
1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. A koan for Considering the Presence of Buddha-Nature in ESMs: I hit myself on the head with a hammer. It hurts. I hit myself again. It still hurts. I hit myself with a padded hammer. It hurts less, but it's still being hit with a hammer -- but it's a familiar pain and I know what to do to treat it. I hit myself on the head with a empty bleach bottle. It still hurts, but it's a different kind of hurt. Here endeth the tale. If you're familiar with RACF elsewhere, then yes, you've already taken the first blow to the head, and it's a familiar pain (but not to the head, or at least not immediately). There are net-new Z sites that don't have RACF/zOS. Considered in the abstract (ie, without a pre-existing RACF investment), RACF *is* really, really ugly compared to VM:Secure or even ACF2. The reasons the alternatives exist is to ameliorate that ugly nature. I've managed systems with all three tools installed at various times. IMHO, RACF's principal advantages are that popular presence on the Other Side, and that you (IBM) own it and can decide to supply it by default if you choose to do so w/o dealing with an outside entity. You can put a lot of lipstick on that pig with RACTOOLS and some front-end execs, but it's still a pig deep down.
Re: Ops privs
Sorry; supporting z/OS DRIVES one to drinking! Kris Buelens [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@listserv.uark.edu 08/27/2007 03:10 PM Please respond to The IBM z/VM Operating System IBMVM@listserv.uark.edu To IBMVM@listserv.uark.edu cc Subject Re: Ops privs I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: Ops privs
A completely uneducated guess would be 50%, and perhaps as high as 90%. Shops that are already comfortable with the IBM mainframe 'mindset' are much more willing, imho, to consider migrating workload to z/VM and Linux than organizations that have no previous mainframe experience. Schuh, Richard wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft
Re: Ops privs
If that is true, then I shudder to think of what the MS Windows people are abusing! I mean, I know that MS apologists are on dreamy dust and have little connection to reality anymore. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Buckles Sent: Monday, August 27, 2007 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs Sorry; supporting z/OS DRIVES one to drinking!
Re: Ops privs
At one time I think I remember Barton mentioning something about getting a lot of business from smaller shops. Of course, it could be dangerous to trust my memory in a critical situation, I couldn't even remember the command for building an NSS this morning. I had to look it up. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Monday, August 27, 2007 1:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs A completely uneducated guess would be 50%, and perhaps as high as 90%. Shops that are already comfortable with the IBM mainframe 'mindset' are much more willing, imho, to consider migrating workload to z/VM and Linux than organizations that have no previous mainframe experience. Schuh, Richard wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft
Re: Ops privs
On 8/27/07, Kris Buelens [EMAIL PROTECTED] wrote: I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. It's a Dutch acronym for Bewust Onbeschonken Bestuurder (deliberately not-drunk driver) Rob (not Bob)
Re: Ops privs
I thought it quite the opposite; you had to be a heavy drinker to drive z/OS (or at least its predecessor). :-) Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, August 27, 2007 1:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
Hello! I happen to know. Coffee. There are more coffee shops, like Starbucks but stranger then the ones around me, in their home city. Disturbing, but true. -- Gregg C Levine [EMAIL PROTECTED] The Force will be with you. Always. Obi-Wan Kenobi -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, August 27, 2007 4:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs If that is true, then I shudder to think of what the MS Windows people are abusing! I mean, I know that MS apologists are on dreamy dust and have little connection to reality anymore. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Buckles Sent: Monday, August 27, 2007 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs Sorry; supporting z/OS DRIVES one to drinking!
Re: Ops privs
On Friday, 08/24/2007 at 06:21 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: My major concern is auditing. While I trust that the implementation will take care of auditing in the ESM, it makes it much harder to see who has been messing with it. Normally when a user tells his server suddenly failed you could scan the PROP logging and see which of the developers reconnected, and tell him to hit his peer over the head with it. But when neither of the virtual machines has its console spooled, you would not be able to tell what happened. Command auditing is already provided by ESMs. Nothing would change in that respect. Oh, and how about RACF restrictions that apply to the LOGON (like terminal or time) ? How would that apply to the proposed commands? No change. The conditional access list for LOGON is not applied to other CP commands. Further, it only applies at the point the user is logged on. Once logged on, those restrictions are never imposed again. No double jeopardy. If you really think this is useful, then use different profiles in the surrogate class (e.g. MAGICBY.target) so that an installation can decide which end users are able to use this. That is what I originally envisioned and remains my fall-back position. Thank you, everyone, for your considered comments. I've gotten what I needed. I should point out, however, that the class G FOR command requires you to be the SECUSER of the target. With an ESM, if you are not the SECUSER, then LOGON BY authority is sufficient. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On 8/26/07, Alan Altmark [EMAIL PROTECTED] wrote: Command auditing is already provided by ESMs. Nothing would change in that respect. It's different type of auditing, with different audience. When I would be paged in the middle of the night, I could search the operator console for smoking guns. Being able to see who was tampering with the thing the night before is enough to divert the call. Many installations will not allow the average support person to run SMF reports. And if they allow, it's not as much fun that I would like you to wake me up for it... Rob
Re: Ops privs
Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. How does bundling RACF change that? 2) Installing RACF or any of the alternatives involves a CP mod. Removing RACF and installing an alternative isn't any more complicated than removing the dummy RPI modules and replacing them with your chosen substitute. 3) How many of the alternatives are getting more than life-support style maintenance? CA doesn't promote VM:Secure any longer (not the strategic solution), and ACF2/VM isn't exactly healthy either. What else is left? 4) RACF (with all it's grotesque hideousness) shares (or can share) development costs with the z/OS version. Is it really worth asking IBM to duplicate that effort in CP just to get ESM functionality, or invent something else (implying all the development, testing, documentation and support) when it's a question of figuring out how to license something that already exists? 5) There are a fair number of places where CP and CMS command logging and authorization is inconsistent or REALLY hard to understand (take SFS auth for starters), and a lot of effort is performed to kludge around the absence of an ESM. Even a horrible ESM like RACF is better than no ESM. Why can't we kick up the base level a notch, if there's a fairly easy way to do it? It just strikes me as a waste of effort to keep kludging around with the base CP security model and inventing half a dozen different ways to do command authorization and logging if we can do it by asking IBM to step up the base model with something that doesn't require them to do (and maintain) new development. -- db
Re: Ops privs
Then you can start on command operand authorization...8-) Oh no... you gave Chucky a new idea. We'll blame you for all that comes out of this. Oh, we've been chatting about this one for a long, long time...he's long since corrupted. The problem is finding a way to juggle priorities to let him do it...8-) Most CP commands right now only allow the ESM to audit, not to control access. If the ESM gets granular access control, we need a a lot of new error messages to reflect that. Or just one: HCPE 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. 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? -- db
Re: Ops privs
On Sat, 25 Aug 2007 00:20:38 +0200 Rob van der Heij said: On 8/24/07, Alan Altmark [EMAIL PROTECTED] wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Put away what you're smoking... Let's get back again to the style where we come up with the requirements and plea for years to get the commands in the directory, and you guys code it ... :-) I understand the idea that these commands achieve things that you could do if you would logon to the virtual machine. Sure, but far from complete: FOR has been suggested, but what about STORE HOST (as long as the frame holds a page of that virtual machine) and DETACH, and... My major concern is auditing. While I trust that the implementation will take care of auditing in the ESM, it makes it much harder to see who has been messing with it. Normally when a user tells his server suddenly failed you could scan the PROP logging and see which of the developers reconnected, and tell him to hit his peer over the head with it. But when neither of the virtual machines has its console spooled, you would not be able to tell what happened. Well, that implies a greater need for logging the auditing. The other system does that via SMF. In VM, that would be either Accounting records or Monitor records. Based on granularity of controlling how much is logged, and the similarity of what is done for other logging uses on VM, I'd recommend Monitor records. ... Rob /ahw
Re: Ops privs (was Re: MAINTENANCE)
Nick Laflamme [EMAIL PROTECTED] wrote: Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Some of us had it beaten into our heads early (by having been IN shops with commands moved around among classes) to document Requires Class A for CP FORCE, XAUTOLOG, and SHUTDOWN and like'a'dat, but yeah, I've seen other vendors who don't do so well... ...phsiii
Re: Ops privs
Alan Altmark [EMAIL PROTECTED] wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? My first thought was, Sure, of course. My second thought was, Well...maybe, but I bet some of the tight-security folks wouldn't like it. My third thought was, Just make the controlling user SECUSER...but then I realized how painful that is for the controlling user to get any work done, as random console output appears from the n controllees. My fourth and final thought (ON THIS TOPIC) was How about another card -- CONTROL user1 user2 user3... usern that would allow all of these for user1 through usern? As z/VM evolves from an end-user environment to a guest host environment (evolves? reverts?), things like this make more and more sense. And would certainly continue the tradition of native, granular control, which some Other Operating Systems don't seem to get... ...phsiii
Re: Ops privs
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Phil Smith III Sent: Saturday, August 25, 2007 12:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs My fourth and final thought (ON THIS TOPIC) was How about another card -- CONTROL user1 user2 user3... usern that would allow all of these for user1 through usern? As z/VM evolves from an end-user environment to a guest host environment (evolves? reverts?), things like this make more and more sense. And would certainly continue the tradition of native, granular control, which some Other Operating Systems don't seem to get... ...phsiii I think maybe it was Rob who suggested ... Make them directory statements like the rest ... AUTOLOG, LNKNOPAS, etc.. I suppose the assumption is that CP would bow to the ESM, the ESM support the statement(s) (or not) ... JR JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED]
Re: Ops privs (was Re: MAINTENANCE)
TCPIP does FORCE and AUTOLOG/XAUTOLOG users Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/23/2007 06:39 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Ops privs (was Re: MAINTENANCE) True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? :-) Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 24, 2007 5:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) TCPIP does FORCE and AUTOLOG/XAUTOLOG users Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/23/2007 06:39 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Ops privs (was Re: MAINTENANCE) True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts?
Re: Ops privs (was Re: MAINTENANCE)
We have a class V that allows class B queries. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Nick Laflamme Sent: Friday, August 24, 2007 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Does anyone else define a class that has all of the QUERYs and other output only classes? I run with class GU on my personal userid -- I can look to make sure all is well, but to actually fix anything (or break it worse), I need to get on something like MAINT. Nick Schuh, Richard wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us?
Re: Ops privs
Indeed, if can can logon to it one can do these things anyhow, only a bit less flexible. And, to complete the list: the authorized user should also be able to work with the spool files of the. We had to code some VMOPER commands to make this possible. 2007/8/24, Alan Altmark [EMAIL PROTECTED]: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs (was Re: MAINTENANCE)
We have class Q for non-classs G QUERY and INDICATE. 2007/8/24, Schuh, Richard [EMAIL PROTECTED]: We have a class V that allows class B queries. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Nick Laflamme Sent: Friday, August 24, 2007 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Does anyone else define a class that has all of the QUERYs and other output only classes? I run with class GU on my personal userid -- I can look to make sure all is well, but to actually fix anything (or break it worse), I need to get on something like MAINT. Nick Schuh, Richard wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Brian Nielsen On Fri, 24 Aug 2007 12:54:22 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do oth er users? Who knows what information it is shipping to Chuckie unbeknownst to us ? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user shou ld implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? =
Re: Ops privs
I think you didn't understand: when a user is aythorized to LOGONBY VMGUEST1, then -as class G user- he should alos be authorized to XAUTOLOG/FORCE of the VMGUEST1 userid. 2007/8/24, Brian Nielsen [EMAIL PROTECTED]: I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Brian Nielsen On Fri, 24 Aug 2007 12:54:22 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do oth er users? Who knows what information it is shipping to Chuckie unbeknownst to us ? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user shou ld implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? = -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
On Friday, 08/24/2007 at 02:49 EDT, Brian Nielsen [EMAIL PROTECTED] wrote: I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? That gives two general classes of action: - manage the guest (start, stop) - BE the guest (start, stop, see, do) Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
No. No. No. No. No. We use LOGONBY as a means of controlling who is allowed to log on to group ids and tracking what they do. None of those other commands would be useful or necessary in that context. Giving those permissions would negate, or at least complicate, our ability to track who did what when. Further, we would not want one user to be able to alter or compromise the functions being performed by another who was already logged on via LOGONBY. SEND, FORCE, and SIGNAL SHUTDOWN certainly have that potential, for example. Most of what is listed could be useful only to someone who is really knowledgeable about the functions of the virtual machine. They are also mostly useful in looking after service machines. They are not useful to someone who is a more naïve user who logs on to a group id to perform simple functions or to run an application program, and could be somewhat dangerous if abused, accidentally or on purpose, by such a person. It is the latter group that we must protect against by not giving them authorities that they will never need. The former group probably has the knowledge needed to function without the added authority. Regards, Richard Schuh There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
On Fri, 24 Aug 2007, Alan Altmark wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? And maybe FOR, in 5.3. At my current job, we create LOGONBY profiles out of laziness - small group, development shop, most of us log onto multiple ids every day, so no one has to remember (or change) any password but their own. In this environment, there would be no issue with bundling all of that with LOGONBY. At my last job (security weasel for a RBC), surrogate facilities like LOGONBY were mostly used to solve the problem of how to provide accountable access by multiple people to a shared security principle (userid) for administration or maintenance, with convenience way down the priority list. Frequently, there was an implied serialization of the resource, too. There, we wouldn't have wanted to see something like this because it would have made collisions less likely to be detected before something bad happened, and auditing more complex if it did. The logic of but they could do it anyway if they can log onto the user is hard to argue against. The question is whether there is really any difference that matters, other than maybe the serialization thing, between doing something while logged on as a user and doing more or less the same thing as or to that user while loggged on as a different user. Steve -- Steve Marak -- [EMAIL PROTECTED]
Re: Ops privs
I like the idea that XAUTLOG authority can me taken as authority to do al l of the Start/Stop functions for that target user and then LOGONBY be take n as complete authority to be that target user. So I could give a server authority (via XAUTOLOG in target users' directories) to XAUTOLOG, FORCE, SIGNAL SHUTDOWN, but not be able to transfer spool files owned by the tar get users or to modify (via SEND) the configuration of the target server. I could reserve for an administrator (via LOGONBY in target users' directories) the authority to manipulate the spool files and machine configuration. I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementat ion. /Tom Kern /301-903-2211 On Fri, 24 Aug 2007 15:52:55 -0400, Alan Altmark [EMAIL PROTECTED] wrote: Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? That gives two general classes of action: - manage the guest (start, stop) - BE the guest (start, stop, see, do) Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
It is definitely necessary to have the exceptions capability, if implemented. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 24, 2007 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? Not a good assumption. I think I'd argue that you should provide a way to individually control each command and ship that with CP. Long term, that's the better solution, and there's a load of stuff that you're dual-pathing now for people that do and don't have an ESM. Much as I dislike RACF, you'd be better off spending the effort to bundle RACF with CP and moving all the command authentication stuff to RACF profiles. You'd solve a lot of other problems in the process, and let sites determine this behavior more granularly than command classes permit today. It would also be a better technology argument vs VMWare and the other Intel virtualization solutions -- they're going to have to invent something very much like RACF in the near future, and you can beat them to the punch. Then you can start on command operand authorization...8-) -- db
Re: Ops privs
I agree with Richard. Not only do you have a serialization issue with multiple people able to issue commands, but all these additional commands would need to be logable by an ESM. I can't think of any cases where I'd want to give SEND or SIGNAL SHUTDOWN authorization to general users. If I did, I'd rather be able to give that authorization individually, and not have it lumped in with Logonby. Dennis O'Brien Chelsea Clinton asked a returning US Soldier about fear. He said there were only three things he was afraid of: Osama, Obama and Yo Mama. -- Truckee Tahoe Times From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, August 24, 2007 13:21 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Ops privs No. No. No. No. No. We use LOGONBY as a means of controlling who is allowed to log on to group ids and tracking what they do. None of those other commands would be useful or necessary in that context. Giving those permissions would negate, or at least complicate, our ability to track who did what when. Further, we would not want one user to be able to alter or compromise the functions being performed by another who was already logged on via LOGONBY. SEND, FORCE, and SIGNAL SHUTDOWN certainly have that potential, for example. Most of what is listed could be useful only to someone who is really knowledgeable about the functions of the virtual machine. They are also mostly useful in looking after service machines. They are not useful to someone who is a more naïve user who logs on to a group id to perform simple functions or to run an application program, and could be somewhat dangerous if abused, accidentally or on purpose, by such a person. It is the latter group that we must protect against by not giving them authorities that they will never need. The former group probably has the knowledge needed to function without the added authority. Regards, Richard Schuh There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
On 8/25/07, David Boyes [EMAIL PROTECTED] wrote: Then you can start on command operand authorization...8-) Oh no... you gave Chucky a new idea. We'll blame you for all that comes out of this. Most CP commands right now only allow the ESM to audit, not to control access. If the ESM gets granular access control, we need a a lot of new error messages to reflect that. Given enough beverages of choice, I could come up with situations where you might want user A to be able to use the DEFSEG command for segment S only. What you do now is to have a disconnected virtual machine with enough privileges and run PROP there. 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). Rob
Re: Ops privs
And to satisfy those installations that are not as simplistic as mine, an ESM implementation could allow an installation to turn it off and use all of the old authorizations just as they are today. Wow, Chuckie must have a distant cousin around here who typed at my keyboard. I don't think I have ever leaned toward implementing something in the ESM when it could be done in CP. /Tom Kern --- Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
Re: Ops privs
And if RACF were a no-cost component of z/VM, I could get away with using it even if the other side of the mainframe runs that other security product. /Tom Kern --- David Boyes [EMAIL PROTECTED] wrote: Not a good assumption. I think I'd argue that you should provide a way to individually control each command and ship that with CP. Long term, that's the better solution, and there's a load of stuff that you're dual-pathing now for people that do and don't have an ESM. Much as I dislike RACF, you'd be better off spending the effort to bundle RACF with CP and moving all the command authentication stuff to RACF profiles. You'd solve a lot of other problems in the process, and let sites determine this behavior more granularly than command classes permit today. It would also be a better technology argument vs VMWare and the other Intel virtualization solutions -- they're going to have to invent something very much like RACF in the near future, and you can beat them to the punch. Then you can start on command operand authorization...8-) -- db Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
Ops privs (was Re: MAINTENANCE)
David Boyes wrote: On our test system, we move SHUTDOWN to class S (or whatever). Then Sounds like a very good idea to implement generically for the next release of VM. Having SHUTDOWN bunched in with all the other class A commands has always been a loaded automatic without a safety. In fact, does OPERATOR really need anything but C and G for normal operations? B would be convenient, but thinking about this as a more general lockdown and cleanup, it might be worth tightening things up a bit now that we're not really doing apps on CMS any more. Actually we never gave our ops class-C ... only sysprogs got that. AFAIK, we never ran into a situation where they needed it. We gave them class E, as we had some tools that might need to display real memory, but never C (look, but don't touch). They also got class-B, though, since they did some manual device management (usually tape drives -- occasionally DASD). And we also had a class override defined for Shutdown. Only ops got that, not sysprogs.
Re: Ops privs (was Re: MAINTENANCE)
Actually we never gave our ops class-C ... only sysprogs got that. The only reason for C would be to enable SET PRIV, which would let us take away all the other privs in the default setup.
Re: Ops privs (was Re: MAINTENANCE)
On Thursday, 08/23/2007 at 12:31 EDT, David Boyes [EMAIL PROTECTED] wrote: Actually we never gave our ops class-C ... only sysprogs got that. The only reason for C would be to enable SET PRIV, which would let us take away all the other privs in the default setup. You don't need class C to manage your own privileges. Also, the new COMMAND statement in the directory makes it easy to do things that were previously a PITA. E.g. you no longer need to give a user class A just so they can SET SHARE when they logon. In the case of SET PRIV: USER ALAN BDEFG : COMMAND SET PRIVCLASS * =G IPL 123 Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
I thought it was for Locking/Unlocking pages, but I'm not sure. Schuh, Richard wrote: True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
