× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi,

This was a question on security and file protection a few months back. A
particular problem was revealed when it was discovered that all standard
user profiles had been created with *ALLOBJ special authority.
This project has simply been shelved after I submitted my findings to the
company.

During this time, because of the lockdown I've been obliged to use a
different developpement environment from home, and have had the pleasure of
discovering ACS as opposed to Client Access which is on my office computer.

When I discovered the window for running SQL scripts and CL commands, I
phoned a user and asked if she could see the same menu options as me. She
said yes, she used the copy and paste functions all the time, but was sorry
to say that she did not understand the utility of most of the other
buttons. I have not yet tried, but I presume she has the possibility of
running exactly the same commands as I do. Ideally, I would have tried a
simple file update from a script from her session to prove this, but I'm
guessing that's really not necessary as her profile has *ALLOBJ special
authority.
So I'm wondering what's the worst thing a user could do in such a scenario?
Drop database? That's a command I've yet to try.

On Fri, 16 Oct 2020 at 17:17, Rob Berendt <rob@xxxxxxxxx> wrote:

Well you're "sort of" right that until you remove *ALLOBJ the users can
still get to the data. Even with your adopted authority setup.

With current versions of the OS there are ways to lock out even QSECOFR
from seeing the actual data. Things like:

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rzahf/rzahfrcactitle.htm
RCAC came out with 7.2.

If you somehow managed to take *ALLOBJ away from everyone, and used
adopted authority, the programs may still need to be modified. Why? Well
if RPG opens a file for update and the user is read only the open will
abort. You will have to program for that exception. Some do this by
having inquiry programs separate from update. I may not have fully
explained this but hopefully you've caught on and if you have questions you
can ask them.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Dave
Sent: Friday, October 16, 2020 10:44 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.


After recounting my findings of our situation and my recommendations
following the advice I’ve obtained to the manager responsable for the
project, I’ve been asked to implement the this solution, and it has left me
scratching my head :



Create a user profile for the data, lets say BANK1

Limit the changing of the data to profile BANK1 only

Change the programs BNKPGM** that modify the data to owner BANK1



All users need to access a menu in our ERP in order to use the programs

Only authorized users will see an option permitting the changing of the
data, others will only be able to consult. This access is controlled by the
ERP.



If the user is authorized, call the program using adopted authority, if
not, call the program without adopted authority





Firstly, if I understand correctly, this will not work – adopted authority
must always or never be used, unless you change the program between calls.
Or maybe you could have an intermediate program, one with USRPRF(*USE) and
the other with *OWNER to get the adopted authorities in one case but not
the other.

Secondly, there seems to me to be no point in creating the new profile and
authorities because (a), all the users have *ALLOBJ special authority and
(b), it’s the ERP that is effectively controlling the access and not the
system.



Thoughts?

Rob Berendt <rob@xxxxxxxxx> schrieb am Di., 13. Okt. 2020, 19:36:

As long as you keep progressing at least those are steps in the right
direction.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Dave
Sent: Tuesday, October 13, 2020 1:02 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.


" But in either case, you are still giving your users *ALLOBJ, just
indirectly. "
I think I get that :
"You're not coming in, you don't have *ALLOBJ'
"Oh yes I do, I'm with the group!"

It doesn't feel right, I agree. But I like the fact that we can get rid
of
*ALLOBJ on the user profiles themselves.
Maybe we could have several groups temporarily, say for example 1 for
each
user department. Then we can pick a guinea pig from each group, take him
out of that group and see what happens. If, after a trial period, there
are no problems, we could remove all members from the group, then delete
the group. With the goal of eventually deleting all the groups

On Tue, 13 Oct 2020 at 15:15, Rob Berendt <rob@xxxxxxxxx> wrote:

I'm really not big on group profiles and have leaned more towards
authorization lists. There's several advantages. One of the most
beneficial is that once you've assigned the authorization list to the
object you can customize it without getting another lock on the object.

But in either case, you are still giving your users *ALLOBJ, just
indirectly. Especially with the group profile. This doesn't solve
anything unless your auditors are complete idiots and just want to
ensure
that individual users do not have *ALLOBJ.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Dave
Sent: Tuesday, October 13, 2020 9:10 AM
To: Midrange Systems Technical Discussion <
midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and
know
the content is safe.


Hi,

I found this interesting page from IBM



https://www.ibm.com/support/pages/preventing-someone-allobj-authority-touching-certain-objects

So if I understand correctly, we would create some group profiles (G1,
G2,
etc) with *ALLUSR special authority, put every user that currently has
*ALLOBJ into one of those groups and remove *ALLOBJ from the users'
personal profiles. At this point, nothing should effectively have
changed.
Next, we could have another group profile (say, GX) with the same
authorities for users of the objects we want to protect. We would then
use
*EXCLUDE (G1, G2, etc) to effectively prevent everyone from using the
protected objects.

As the page says, it is not recommended, but should work. Seems like a
kind
of upside down approach to me. But we would at least have removed
*ALLOBJ
special authority from each user. Maybe it's a start!










On Thu, 1 Oct 2020 at 15:18, Rob Berendt <rob@xxxxxxxxx> wrote:

According to https://www.ibm.com/support/pages/node/6023368
that can be upgraded to 7.3. This would be a big help with security
tools.

Biggest concern with an upgrade from 7.1? Maybe the old SSL
certificates
which are no longer supported with newer versions. But is this a bad
thing? Plus you get newer SSL versions which people will actually
accept.

Usual required stuff to say:
- Read the Memo to users for both 7.2 and 7.3. I do mean BOTH.
- Check with your software vendors to see if the version you are
running
is supported on a higher release or if you need to put on a new
version.
MTU for 7.2:



https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzahg/rzahgmtu.htm
MTU for 7.3:



https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzahg/rzahgmtu.htm
Upgrading to 7.3:



https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzahc/rzahcupgradeorreplace.htm


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of
Dave
Sent: Thursday, October 1, 2020 8:47 AM
To: Midrange Systems Technical Discussion <
midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization. Do
not
click links or open attachments unless you recognize the sender and
know
the content is safe.


8202-E4C

Rob Berendt <rob@xxxxxxxxx> schrieb am Do., 1. Okt. 2020, 13:55:

Let's try
WRKHDWRSC TYPE(*PRC)
What's the first entry under "Type-model"? In my case it is
9009-42A.
Basically I am trying to see if there's a chance you can upgrade
the
OS
to
a newer version which will be better at supporting some
suggestions I
have
in mind.
https://www.ibm.com/support/pages/node/6023368

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf
Of
Dave
Sent: Thursday, October 1, 2020 7:32 AM
To: Midrange Systems Technical Discussion <
midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization. Do
not
click links or open attachments unless you recognize the sender and
know
the content is safe.


I've discovered that when the company bought their new machine in
2013,
they suddenly started having problems with user authorities and
found
it
necessary to add *ALLOBJ to All the user profiles!!
I'm guessing it was QSECURITY that changed and new users didn't
have
the
authority necessary
What those authorities are I don't yet know
I was looking for a command to extract all the authorities on the
system
but that doesn't look that easy.
Then I thought why not create a user profile with no special
authorities
and see how it affects me when I use it.

Rob Berendt <rob@xxxxxxxxx> schrieb am Di., 29. Sept. 2020, 15:43:

I'll give you an example. Here it was discovered that the users
had
an
initial program which jumped them directly into our ERP package.
They
also
had limited capabilities set to yes, which basically means no
command
line. They had no special authority. However, instead of their
initial
menu being *SIGNOFF it was set to QSYS/MAIN. Actually this is a
current
issue I'll get around to one of these days...

MAIN
4. Files, libraries, and folders
...
6. Query Utilities
7. Data File Utility (DFU)

4. Files, libraries, and folders
1. Files
1. Work with files
File . . . . . . . . . . . . . . *ALL
Library . . . . . . . . . . . ERPLXF
4=Delete

Yet another reason we are going to implement "Application Only
Access".

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 7310 Innovation Blvd, Suite 104
Ft. Wayne, IN 46818
Ship to: 7310 Innovation Blvd, Dock 9C
Ft. Wayne, IN 46818
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On
Behalf
Of
Charles Wilt
Sent: Tuesday, September 29, 2020 9:24 AM
To: Midrange Systems Technical Discussion <
midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: File protection basics

CAUTION: This email originated from outside of the organization.
Do
not
click links or open attachments unless you recognize the sender
and
know
the content is safe.


On Tue, Sep 29, 2020 at 12:59 AM Dave <dfx1@xxxxxxxxxxxxxx>
wrote:


This may be a silly question, but I'll ask anyway: why not just
let
the
program check the user id before allowing any particular level
of
access
to
the files? I'm guessing that in this situation, that may be
necessary,
given the fact that everyone has special authority *ALLOBJ.


Because the fact that users have *ALLOBJ means they don't have to
use a
program to read/change/delete data...or even the program objects.

If you don't already have this book, I highly recommend it.






https://www.amazon.com/Security-Administration-Compliance-Woodbury-2016-05-11/dp/B01JXQM65I

Charles
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: https://amazon.midrange.com


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.