Re: Commands for Limited Users

Well, actually, at this point, that IS the point... I haven't gotten to
the "other" file systems yet. So, at this point, I'm still goin' down
the golden brick road. The problem is that I can't see all the dips that
are ahead of me in that road which will require a different methodology.
Therefore my question about what the swapping looks like...

Dave 

-----Original Message-----
From: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
[mailto:security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of [email protected]
Sent: Thursday, September 07, 2006 1:04 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

No Dave, that isn't the point.  That "was" the point.  But if you look
at John's last sentence.
<snip>
But adopted authority has a serious shortcoming that limits it's
usefulness in the file systems that the majority of new applications
would use. 
</snip>

If I do a
MD DIR('/scratch')
CHGAUT OBJ('/scratch') USER(*PUBLIC) DTAAUT(*EXCLUDE) OBJAUT(*NONE)
CHGOWN OBJ('/scratch') NEWOWN(BUBBA)

A program that adopts the authority of BUBBA will still not have
authority to data in this directory.  You need to do profile switching
to get access.  See the profile handle api's at
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/sec1.ht
m

An example of profile handling is if you use any netserver drives on
your i5, or if you use WDSC or any other such client server application.
Then you could do a WRKOBJLCK OBJ(MYID) OBJTYPE(*USRPRF) In there you
will find jobs that are running under one user id, but "servicing"
another.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com


"Turnidge, Dave" <DTurnidge-jXHaHu7tDRvNHyFk3Yt2uVaTQe2KTcn/@public.gmane.org> 
Sent by: security400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
09/07/2006 01:51 PM
Please respond to
Security Administration on the AS400 / iSeries
<security400-Zwy7GipZuJhWk0Htik3J/[email protected]>


To
"Security Administration on the AS400 / iSeries" 
<security400-Zwy7GipZuJhWk0Htik3J/[email protected]>
cc

Subject
Re: [Security400] Commands for Limited Users

But, isn't that the point? In our case, all production objects are owned
by one user profile. When a user comes through a menu, they adopt that
owning profile's authority. Outside of the menu, (as in other methods of
access), they don't have authority, unless it is granted individually,
or to a group profile.

-----Original Message-----
From: security400-bounces+dturnidge=oldrepublictitle.com-Zwy7GipZuJhWk0Htik3J/[email protected]
[mailto:security400-bounces+dturnidge=oldrepublictitle.com-Zwy7GipZuJhWk0Htik3J/[email protected]]
On Behalf Of John Earl
Sent: Thursday, September 07, 2006 12:47 PM
To: Security Administration on the AS400 / iSeries
Subject: Re: [Security400] Commands for Limited Users

Edwin,

> Correct me if I am wrong, but the proper way to secure this object 
> would be to have *public with *exclude, "/Serviceprofile/" with *all 
> (or as
> needed) and
> then do a
> CHGPGM /pgmname/ USRPRF(*owner) to adopt the service profiles 
> authority.
> Then do a CHGOBJOWN OBJ(/pgmname/) OBJTYPE(*PGM)
> NEWOWN(/Serviceprofile/)
> which will make the owner of the program the service profile.

If you accuse me of being a stickler for detail on this point, I'll
accept the charge, but I would characterize the authorization scheme you
have outlined here is an "adopted authority" scheme rather than an
"object authority" scheme.  To me an object authority scheme is one
where all users of a file are granted authority to that file either
directly, through one of their group profiles, or via an authorization
list, and an adopted authority scheme is one where no users are allowed
direct access to the data unless they go through an approved interface,
and that interface is able to provide the requisite authority to get the
job done. 

I like, and use, adopted authority schemes.  But I don't think they are
the same thing as object authority (maybe that is just my own semantic
bugaboo).  I'm also aware of the limitation that threatens their
obsolescence (the fact that adopted authority is not supported in file
systems other than QSYS.LIB).  Most of the newer web based applications
are use objects in file systems other than QSYS.LIB, so a traditional
adopted authority scheme will not be effective. 

And this is the point that leaves me confused about the whole "object
level security" promotion.  Most of the folks that I have heard promote
OLS as "the correct way" to do secure a System i, don't really mean OLS,
they mean "adopted authority".  But adopted authority has a serious
shortcoming that limits it's usefulness in the file systems that the
majority of new applications would use. 


jte

--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl-Ua2wos9bJ7y1Z/[email protected]
www.powertech.com
Celebrating our 10th Anniversary Year!
 

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.