RE: Adopted authority vs profile switching

[rob@xxxxxxxxx]

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.