RE: Adopted authority vs profile switching

[rob@xxxxxxxxx]

But they've already introduced that security exposure by supporting 
profile switching.  So why not just have adopted authority work in the 
first place?

I understand what you are saying about changes breaking other code.  But I 
don't find that applicable in this case.  I can already create a program 
that does a CALL QCMD, owned by QSECOFR and any user can run it and then 
execute the following command:
CRTUSRPRF USRPRF(DELME) USRCLS(*SECOFR)
But they can't run this command:
CRTUSRPRF USRPRF(DELME2) USRCLS(*SECOFR) GRPPRF(SSA) OWNER(*GRPPRF)
CPF9802-Not authorized to object SSA in QSYS.
But then user DELME can sign on and do CHGUSRPRF DELME GRPPRF(SSA) 
OWNER(*GRPPRF)

How does forcing people to use profile switching make this any more 
secure?  Security by obscurity?  Is there some system value that says 
allow adopted authority but not profile switching?  If so, is it so 
draconian that activating it effectively kills all client server 
applications and makes it so that no one uses this system value?

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/19/2004 10:48 AM
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 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.


--
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.