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
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
: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
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
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 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
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
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
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
, 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
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
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
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
] -
-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
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.
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
, 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
3:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Ops privs
Sorry; supporting z/OS DRIVES one to drinking!
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
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
: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
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
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
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
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?
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
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
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,
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,
-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
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
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
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
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
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]:
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
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]
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
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
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
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
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,
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
: 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
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
, 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
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
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
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
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.
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.
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
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
[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
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
71 matches
Mail list logo
