RE: Adopted authority vs profile switching

["John Earl" <john.earl@xxxxxxxxxxxxx>]

Rob,

I bet you're going to hate this answer but...

> I wasn't looking it as a security exposure.  I was looking
> at it as "Why
> block using adopted authority in the first place if they
> are going to give
> you some other workaround?".

Adopted authority was created first.  It has certain limitations, but
those limitations have been there for quite some time.  Because IBM as a
whole (and Rochester in particular) hate to break existing customer
code, I don't think you'll find much appetite for changing (fixing?) the
way adopted authority works - the potential for breaking existing
customer code (or in this case introducing a security exposure) is to
high.  :(

jte


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Monday, July 19, 2004 7:52 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Adopted authority vs profile switching
> 
> John,
> 
> In some of the cases, no, adopted authority does not run
> with BOTH
> authorities.  Instead it seems to run with neither.  Like
> CRTUSRPRF with
> certain group profile information.
> 
> I wasn't looking it as a security exposure.  I was looking
> at it as "Why
> block using adopted authority in the first place if they
> are going to give
> you some other workaround?".
> 
> I tried using SCNMSGF to find that exact message id again,
> but I can't
> find it now.
> 
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "John Earl" <john.earl@xxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 07/16/2004 08:55 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-
> l@xxxxxxxxxxxx>
> 
> 
> To
> "Midrange Systems Technical Discussion" <midrange-
> l@xxxxxxxxxxxx>
> cc
> 
> Subject
> RE: Adopted authority vs profile switching
> 
> 
> 
> 
> 
> 
> Rob,
> 
> I don't really understand the question, because profile
> switching and
> adoption are two pretty different things.
> 
> When I run a program that adopts your authority, I am now
> running with
> my authority + your authority.
> 
> If I switch to your profile, I am no longer carrying any
> of my
> authority, I only have your authority.
> 
> So switching is a new capability, not a replacement of an
> old
> capability.
> 
> Also, to answer the question of the "security exposure"
> that switching
> might introduce, I don't really see it.  If I have *USE
> authority to
> your profile I can assume your identity in a number of
> ways.  Yes I can
> switch to it, but I also can submit a job as you, or add
> your name to a
> JOBD and have any number of batch, pre-start, or
> communications jobs run
> as you.  So the profile switching API's are a natural
> extension of
> capability that is already out there.  They don't
> introduce any new
> security exposures, thought they may highlight some
> existing ones (such
> as the fact that some of your users have *USE or better
> authority to
> other users profiles).
> 
> JMHO,
> 
> jte
> 
> 
> 
> --
> John Earl | Chief Technology Officer
> The PowerTech Group
> 19426 68th Ave. S
> Seattle, WA 98032
> (253) 872-7788 ext. 302
> john.earl@xxxxxxxxxxxxx
> www.powertech.com
> 
> 
> 
> This email message and any attachments are intended only
> for the use of
> the intended recipients and may contain information that
> is privileged
> and confidential. If you are not the intended recipient,
> any
> dissemination, distribution, or copying is strictly
> prohibited. If you
> received this email message in error, please immediately
> notify the
> sender by replying to this email message, or by telephone,
> and delete
> the message from your email system.
> --
> 
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-
> l-
> > bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> > Sent: Friday, July 16, 2004 7:58 AM
> > To: midrange-l@xxxxxxxxxxxx
> > Subject: Adopted authority vs profile switching
> >
> > At one time IBM decided that using adopted authority
> > should not work in
> > certain situations, like creating certain group
> profiles,
> > etc.  Perhaps
> > they thought this was a security enhancement.
> > Then they allowed a workaround with profile switching.
> >
> > So then, does this not allowing adopted authority in
> these
> > situations now
> > go into the realm of 'security by obscurity' and should
> > they just open
> > these up to adopted authority?  Or do you see a value
> into
> > making people
> > use these api's to do profile switching, - in this
> > situation - ?
> >
> > Now, I am not arguing that profile switching may not be
> > useful in some
> > client serving or web based applications.  I am just
> > arguing about it in
> > the first situations.
> >
> > Rob Berendt
> > --
> > Group Dekko Services, LLC
> > Dept 01.073
> > PO Box 2000
> > Dock 108
> > 6928N 400E
> > Kendallville, IN 46755
> > http://www.dekko.com
> >
> > --
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> > http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/midrange-l.
> 
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.