Restore and loss of private rights

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
Thanks John. Then, if what you say is correct (rights stored on the user
profile), why do I still lose those rights when restoring a file in the same
library ?

Said differently, if we save a file on a tape, and then just restore this
same file on the original data, we still loose those rights.

Daniel


-----Original Message-----
From: security400-request@midrange.com
[mailto:security400-request@midrange.com]
Sent: jeudi, 23. août 2001 19:01
To: security400@midrange.com
Subject: Security400 digest, Vol 1 #9 - 7 msgs


Send Security400 mailing list submissions to
        security400@midrange.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/cgi-bin/listinfo/security400
or, via email, send a message with subject or body 'help' to
        security400-request@midrange.com

You can reach the person managing the list at
        security400-admin@midrange.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Security400 digest..."


Today's Topics:

   1. Re: Authority annoyances, continued... (John Earl)
   2. Re: Restore and loss of private rights (John Earl)
   3. Re: Welcome to the Security400 Mailing List @ Midrange.com ! (John
Earl)
   4. Re: Authority annoyances, continued... (John Earl)
   5. RE: Authority annoyances, continued... (Joe Giusto II (E-mail))
   6. RE: Authority annoyances, continued... (Bale, Dan)
   7. Re: Authority annoyances, continued... (John Earl)

--__--__--

Message: 1
From: "John Earl" <johnearl@powertechgroup.com>
To: <security400@midrange.com>
Subject: Re: [Security400] Authority annoyances, continued...
Date: Wed, 22 Aug 2001 17:39:46 -0700
Organization: The PowerTech Group
Reply-To: security400@midrange.com

Dan,

I agree with the poster who asked why this was different/better than
just creating an adopted authority program.  It can be significantly
less secure than an adopted authority routine.

> Create a user on the system (eg. BACKUPUSER) with no password
(password
> *NONE). Ensure this user has the required authority to do the back
up. A
> good way to achieve this is to put the user into the QSECOFR group,
make the
> group the owner of all objects created by this user.
>
> Create a job description that will be used to submit the back up job
to
> batch. Ensure that the USER parameter of the job description
specifies the
> new user (eg. USER(BACKUPUSER)). Any job submited to batch using
this job
> description will then run under the new user profile.

This last line may be much truer than you wish.  On a security level
30 machine, this JOBD would be usable by any user, for any purpose
they desire, unless you specifically restrict access to the JOBD.

If you choose this route, please be sure to secure the JOBD to *PUBLIC
*EXCLUDE and then specifically give the user who will be submitting
this job *USE authority to the JOBD.  This will prevent other users
from misappropriating this JOBD.

It may not prevent the original user from mis-using this JOBD though.
Once you give them authority to use the JOBD, it may be difficult or
impossible to control what they use the JOBD for.

An adopted authority routine that does a very specific thing, and
adopts the necessary authority for a finite period of time can provide
a much more secure route to your destination..

jte


--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com



--__--__--

Message: 2
From: "John Earl" <johnearl@powertechgroup.com>
To: <security400@midrange.com>
Subject: Re: [Security400] Restore and loss of private rights
Date: Wed, 22 Aug 2001 22:53:10 -0700
Organization: The PowerTech Group
Reply-To: security400@midrange.com


Daniel,

> Hi all. When restoring a database, we lose private rights on
objects. Anyone
> having an idea how to solve this issue ? If it's a system bug, does
a
> solution come with V5R1 ?
>

This question is close enough to a question that I just answered on
the Midrange-L that I hope you don't mind me just replaying that
question and answer.   If this doesn't answer your question, let me
know and I'll take another shot at it.


                                                ###

> I was wondering why when I save a program with private
> authorities to a save file and then restore the
> program to a different library I lose the private
> authority.

Actually, you don't lose the private authorities, they are right where
they always were.  :)   Private authorities to an object (such as a
file) are stored in the user profile object, and not in the file
object.  That's an important thing to understand about private
authorities...

So if you save a copy of file "ITEM", and then restore the file to
another library, PHIL's profile still records the fact that he has
*ALL authority to the original "ITEM" file.  This newly restored file
"ITEM" in a new library?  Well User Profile PHIL has never even been
told that this new file exists, so it can't be authorized to it.
(This would mean that the suggested RSTAUT command would not work
either)

If you want object level security, then every time you introduce a new
object to your system you must manage the authority to that new
object.  There is no "automatic security feature" that will guess what
authority you want assigned to new objects, so you have to do it
yourself.

In this case I would recommend that after you restore the object, run
the GRTOBJAUT command, and use the original "ITEM" file as a
"referenced object".  It's one extra step, but it will get you want
you want.

                                                ###

jte

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com


--__--__--

Message: 3
From: "John Earl" <johnearl@powertechgroup.com>
To: <security400@midrange.com>
Subject: Re: [Security400] Welcome to the Security400 Mailing List @
Midrange.com !
Date: Wed, 22 Aug 2001 22:57:27 -0700
Organization: The PowerTech Group
Reply-To: security400@midrange.com

Phil,

> On the Code/400 list we were talking about how to open an IFS file
from Code
> Edit.  It opens a java app that allows you to browse the IFS
(including
> qsys.lib)  The folders do not need to be shared through OpsNav, a
version of
> client access that supports mapping drives doesn't need to be
installed, and
> the QFWPSERVER authorization list doesn't prevent access to
qsys.lib.
>
> I have had no trouble securing folders other than qsys.  QSYS,
however, is
> much more difficult because many apps require users to do things
users
> normally aren't authorized to do (ADDPFM, RMVPFM etc) so authority
is lax.
>
> Has anyone gone though another vendor's app, changed all file
authorities to
> public *exclude, change the owner to a profile that can't sign on,
and then
> change the initial programs to use adopted authority *owner?

I can't answer the question as asked, but it is worth noting that the
IFS does not support the adopted authority concept.  You can define
your programs as USRPRF(*OWNER), it's just that the adopted authority
will not work when accessing objects outside of QSYS.LIB.   You'll
have to use some other authority method in the IFS.

jte

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com


--__--__--

Message: 4
From: "John Earl" <johnearl@powertechgroup.com>
To: <security400@midrange.com>
Subject: Re: [Security400] Authority annoyances, continued...
Date: Thu, 23 Aug 2001 00:58:44 -0700
Organization: The PowerTech Group
Reply-To: security400@midrange.com


> QSYSOPR wouldn't be able to do that. It checks to see if you have
authority
> to the user profile on the job description.  The sbmjob would fail
with a
> "not authorized to profile" message.

True for QSECURITY level 40 machines.  But if the machine is at
QSECURITY level 30 or less, the sbmjob would be successful if the user
merely has *USE authority to the JOBD.

jte


>
> -----Original Message-----
> From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
> Sent: Wednesday, August 22, 2001 12:00 PM
> To: security400@midrange.com
> Subject: RE: [Security400] Authority annoyances, continued...
>
>
> >Create a job description that will be used to submit the
> >back up job to batch. Ensure that the USER parameter
> >of the job description specifies the new user (eg.
> >USER(BACKUPUSER)). Any job submited to batch
> >using this job description will then run under the new user
profile.
>
> Not a guru, so this may be wrong, but can't I (a mere operator) do:
sbmjob
> cmd(grtobjaut...) jobd(backupjobd) and give myself authority to
anything?
> Why is this better than having the CL program adopt required
authority?
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries
(Security400)
> mailing list
> To post a message email: Security400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/security400
> or email: Security400-request@midrange.com
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries
(Security400) mailing list
> To post a message email: Security400@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/security400
> or email: Security400-request@midrange.com
>

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com


--__--__--

Message: 5
From: "Joe Giusto II \(E-mail\)" <juicenetdps@crosswinds.net>
To: <security400@midrange.com>
Subject: RE: [Security400] Authority annoyances, continued...
Date: Thu, 23 Aug 2001 09:48:57 -0400
Reply-To: security400@midrange.com

If memory serves me correctly, didn't the SYS38 default objects to public
exclude (or maybe it was just use)?  I seem to remember always having
trouble with object authority when ever we changed employees.  As the new
operator would run jobs during the first week or so, we would have to keep
granting object authority to files as programs blew up.  This was of course
before we learned about the group profiles which eliminated that need once
implemented.  We granted proper authority to the group profiles and then
just started adding profiles to the group when new person came.

Joe Giusto II
Programmer/Analyst
Ritz Camera
Beltsville, MD
301-419-3209 x347
410-813-2812 x347

 -----Original Message-----
From:   security400-admin@midrange.com
[mailto:security400-admin@midrange.com]  On Behalf Of John Earl
Sent:   Wednesday, August 22, 2001 8:04 PM
To:     security400@midrange.com
Subject:        Re: [Security400] Authority annoyances, continued...


<snip>

Now, we sell exit programs, and make our living (in part) off of this
"hole" that was opened up - but I must insist - please, don't blame
IBM.  They didn't do it.  The hole was created by us (you and I ) and
all the other developers and (especially) application vendors that
built our systems to rely on "menu security".  IBM told us not to do
it.  IBM gave us object level security.  We just chose not to use.   I
agree that the /400 world is in a very messy place with respect to
security, I just don't think you can saddle IBM with the blame.

<snip>

jte

--
John Earl - VP & CTO
The Powertech Group
253-872-7788
johnearl@powertechgroup.com
www.powertechgroup.com




--__--__--

Message: 6
Subject: RE: [Security400] Authority annoyances, continued...
Date: Thu, 23 Aug 2001 10:15:27 -0400
From: "Bale, Dan" <D.Bale@handleman.com>
To: <security400@midrange.com>
Reply-To: security400@midrange.com

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Um, wait, I'm getting lost here.  Was it me you were responding to?
(Not too many Dan's on the list, so I'm assuming.)

Are you differentiating an adopted authority program from an adopted
authority routine?  If so, how are they different?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com

> -----Original Message-----
> From: John Earl [SMTP:johnearl@powertechgroup.com]
> Sent: Wednesday, August 22, 2001 8:40 PM
> To:   security400@midrange.com
> Subject:      Re: [Security400] Authority annoyances, continued...
>
> Dan,
>
> I agree with the poster who asked why this was different/better than
> just creating an adopted authority program.  It can be significantly
> less secure than an adopted authority routine.
>
> > Create a user on the system (eg. BACKUPUSER) with no password
> (password
> > *NONE). Ensure this user has the required authority to do the back
> up. A
> > good way to achieve this is to put the user into the QSECOFR group,
> make the
> > group the owner of all objects created by this user.
> >
> > Create a job description that will be used to submit the back up job
> to
> > batch. Ensure that the USER parameter of the job description
> specifies the
> > new user (eg. USER(BACKUPUSER)). Any job submited to batch using
> this job
> > description will then run under the new user profile.
>
> This last line may be much truer than you wish.  On a security level
> 30 machine, this JOBD would be usable by any user, for any purpose
> they desire, unless you specifically restrict access to the JOBD.
>
> If you choose this route, please be sure to secure the JOBD to *PUBLIC
> *EXCLUDE and then specifically give the user who will be submitting
> this job *USE authority to the JOBD.  This will prevent other users
> from misappropriating this JOBD.
>
> It may not prevent the original user from mis-using this JOBD though.
> Once you give them authority to use the JOBD, it may be difficult or
> impossible to control what they use the JOBD for.
>
> An adopted authority routine that does a very specific thing, and
> adopts the necessary authority for a finite period of time can provide
> a much more secure route to your destination..
>
> jte
>
>
> --
> John Earl - VP & CTO
> The Powertech Group
> 253-872-7788
> johnearl@powertechgroup.com
> www.powertechgroup.com

--__--__--

Message: 7
From: "John Earl" <johnearl@powertechgroup.com>
To: <security400@midrange.com>
Subject: Re: [Security400] Authority annoyances, continued...
Date: Thu, 23 Aug 2001 07:57:35 -0700
Organization: The PowerTech Group
Reply-To: security400@midrange.com


> Um, wait, I'm getting lost here.  Was it me you were responding to?
> (Not too many Dan's on the list, so I'm assuming.)

Yes


> Are you differentiating an adopted authority program from an adopted
> authority routine?  If so, how are they different?

No - No difference in my book.

jte





--__--__--

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400)
digest list
To post a message email: Security400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/security400
or email: Security400-request@midrange.com



End of Security400 Digest


**********************************************************************
This E-mail and any files transmitted with it are confidential
and intended for the exclusive use of the addressee(s) only.
 You should not disclose its contents to any other person.
If you are not the intended recipient please notify the sender
immediately.
**********************************************************************