Re: File protection basics -- MIDRANGE-L

To Dave et al. about ACS - the buttons you see are managed by a config file - AcsConfig.properties - there is a section there that lists the functions or actions a user has.

There are actions that I believe are not needed by the typical end user - database is one they probably don't need easy access to, especially in your situation with *ALLOBJ.

Printed output is a good one for people, but security may be far too open to allow it generally.

Run SQL statements? Security by obscurity is NOT your friend here!!

There are a couple documents included with ACS - a quick start and a general setup document.

There are also several online docs - I found a pair by Bob Seeman that might be worth a look -

https://developer.ibm.com/articles/i-ibmi-access-client-solutions-customization-trs/
https://developer.ibm.com/technologies/systems/articles/i-ibmi-access-client-solutions-2/

Regards
Vern

On 3/19/2021 8:04 PM, Don Brown via MIDRANGE-L wrote:

*ALLOBJ means All Object Authority which means the user has total
authority to every object on the system.

So any object can be read, updated and deleted.

I would suggest a review of your object authority and put together a list
of real requirements.

Also there are many good publications on the subject and also the IBMi
Knowledge Centre - invest in some research and then ask questions here if
not sure.

Then create a test set of;

User profiles
Group user profile
Authority lists

Then in a test environment assign the authority list(s) to the objects and
test with the test user profiles that the user can still do their job.

Once you have a working test set of profiles etcetera then you could start
to deploy the solution to the production environment.

There have been many discussions on this subject. Rob Berendt has posted
many good comments and solutions and generally includes the comment of not
wanting to play "Whack-a-Mole" which in this case means protect the data.

Cheers

Don

From: "Dave" <dfx1@xxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxxxxxxxx>
Date: 20/03/2021 10:18 AM
Subject: Re: File protection basics
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx>

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