Talking about an OBJECT in the IBMi world conjures up images of all kinds of wonderful screens defining object parameters:
AS400 iSERIES and IBM i Object Authority
Question: If a library has security for a user of *USE will this user be able to update files in the library and If files were created with public *USE.
Or is the security level at the library used for all objects under it. My understanding is that the library *USE means the user can use all objects under it and that the security of the files (objects) is used to check what the user can do to the file.
Answer You are correct, having Use to the library means you cant add objects to that library, but if a file has *PUBLIC *CHANGE inside a library that you only have *USE to, you can still change the data in the file
*USE at the library level will let a user pretty much do anything to an object in that library that is not excluded by authority on that object. One exception I’ve found is the ability to add a member to a file, which requires *CHANGE at the library level.
*USE on the object level only lets a user read data in a file – not change it. Note that they could download the file to a PC (but couldn’t upload & overlay). So take this example:
Library authority *USE
FILE1 – *PUBLIC *USE <- USER1 can read file
FILE2 – *PUBLIC *ALL <- USER1 can change data in file
FILE3 – *PUBLIC *ALL, USER1 *EXCLUDE <- USER1 cannot access file
Question. I would like to find (if one indeed exists) something that has a listing of all the CL commands and what authority they need to run them. Is there such a thing out there? I have looked in all my CL reference guides with no luck.
Answer 1. Appendix D. Authority Required for Objects Used by Commands in OS/400 Security – Reference SC41-5302 contains the list of commands and authorities required.
(http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3ALC02/CCONTENTS)
Question: I am in the process of securing some of our data and was wondering if someone could answer if the following assumption would be correct.
I have
LIBRARYA with FILE1 and FILE2. LIBRARYB with VIEW1 which points to FILE1 and FILE2 in LIBRARYA
Now for the fun part. USER1 does not have any authority to LIBRARYA at all but does have *USE authority to LIBRARYB and VIEW1.
Would USER1 be able to view the data from LIBRARYA in FILE1 and FILE2 through VIEW1.
Answer 1. NO WAY.
Your user profile would be able to “see” object description or member description of logical, but it won’t be able to retrieve data from library in which physical file resides unles it has at least EXECUTE rights to that library. It also has to have “READ” right to physical file.
Question. *PUBLIC’s authority to an object is stored in the object itself. But where exactly is it kept? If you do a DSPOBJD to an outfile, it doesn’t show up as a field in the outfile, does anyone know how to retrieve it?
Answer 1. Use the command DSPOBJAUT
Answer 2. Object authority is stored in the Header. Try using the DMPOBJ command … It shows the *PUBLIC authority attribute. Here is an example DMPOBJ listing…
See under ” SPACE- ” … the value of *USE is the *PUBLIC authority to this object…
SPACE-
000000 C0E80000 04200001 00000000 00D50000 00000000 00005CE4 E2C54040 40404040 *{Y N *USE *
000020 00000000 00000000 012B0000 00000000 0000003C 00000100 40000000 00F0F9F8 * 098*
This dump seems to vary by object type. If you dump a database file you get the space information. If a display file you also get the space info, but the public authority seems to be in a different place. If a program, no space information, no public authority. This doesn’t seem to be a very general or reliable method, and you might get changes from release to release.
Answer 2 Footnote. The authority is stored differently according to different object types. The architected method for fetching the public authority is the MATAU instruction which is exposed via the QSYRUSRA API DSPOBJD shows the information returned by the MATSOBJ instruction (and some other stuff). It is interesting that the MATSOBJ instruction will return authorization list information but not public authority.
Answer 3. The Retrieve User Authority to Object (QSYRUSRA) API supports the special value *PUBLIC for the User profile name parameter. The List Users Authorized to Object (QSYLUSRA) API can also be used to determine public authority as the first entry returned in the list is for *PUBLIC. Both APIs are found in the Security chapter of the System API Reference.
Question: We just received the *official* findings of an audit that was done in June of this year on our Model 530 AS/400. In his findings, the auditor is wanting the system value QCRTAUT changed from *CHANGE to *USE….
According to Al Barsa’s COMMON handout on system values, the CRTAUT parameter for the libraries QSYS and QGPL should be changed to *CHANGE before changing the system value. Are there any other IBM supplied ‘Q’ libraries that I should be concerned about changing as well???
Answer: I have recent experience in changing QCRTAUT to *EXCLUDE, and with two notable exceptions it has been a breeze.
The exceptions are device creation and message queue creation. Because both QSYS and QUSRSYS have been changed to *EXCLUDE, we have to manually authorize folks to newly created device descriptions and their associated message queue’s. This is not a big problem as there is the system has Authorization Lists for both of these object types. We just have to remember to add newly created Device and Message queue’s to the list.
Question: We are looking for a way to secure our files from ODBC, DFU, File Transfer etc etc What I would like to do is restrict user access to the files to using programs only. I would like to give the programs access to the files and not the user. We have been a S36 shop and are converting over and as part of this conversion would like to secure all production files from unauthorized access. The S36 setup is really poor security.
I know I can restrict the commands that will access the files CPYF, DFU etc but there are more and more ways to get at the DATA and if you miss one (such as FTP) then you really don’t have any security.
Also certain people (Programmers) will need to use some of these but not on production files.
Answer 1. One way to secure files from access other than by programs is to have them owned by one user profile. This profile is not a group profile. Then all your programs use that user profile. For example:
CHGOBJOWN OBJ(FILELIB/FILEA) OBJTYPE(*FILE) NEWOWN(SECUREGUY) GRTOBJAUT OBJ(FILELIB/FILEA) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE) CHGOBJOWN OBJ(PGMLIB/PGMA) OBJTYPE(*PGM) NEWOWN(SECUREGUY) GRTOBJAUT OBJ(PGMLIB/PGMA) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE) CHGPGM PGM(PGMLIB/PGMA) USRPRF(*OWNER) USEADPAUT(*YES)
Answer 2. Check out adopted authority. Some don’t like it but you essentially revoke all authority to all data files to all users. Grant file authority to the creator of a program, grant the user authority to the program and have the user adopt the owners authority during the running of the program.
This way even if a user is granted authority to DFU, they are blocked at the file level. The only DFU that could be run against a file would have a CL wrapper and appropriate authorities.
Answer 3. I’ve just been wrestling with this also. You can certainly use adopted authority to access the database, but look at the security APIs. It will get pretty complicated if you try to adopt the program owner’s authority. I rejected this because it doesn’t seem to work very well with the package software that we have, but it may work for you. Here’s what I’ve come up with so far:
Only grant update access to the objects that the user will actually be updating. We allow read access to virtually everything else (company policy), so there are plenty of spreadsheets, Access databases and crystal reports. That’s a good use for ODBC.
For interactive users, remove the command line, only let them run the programs that they need to run in order to do their jobs, and make them use the menus. They’re all LMTCPB(*YES).
Use exit programs to prevent updating of ANYTHING in a production library by ODBC or FTP unless the exact command has been registered as a permissible command (not really as difficult as it sounds, but I still have some work to do on that part). The preferred method of updating the data is via server programs on the AS/400. Remember that Client Access users can issue commands using Remote Command regardless of whether they are defined as LMTCPB(*YES), so exit programs are essential here.
Since FTP enforces the LMTCPB setting (ODBC doesn’t), and since some file transfers require an AS/400 update job to be invoked, provide a special version of the CALL command that allows LMTCPB users to run it, in a library that has no public access, and is available only to a very special user profile that can do nothing but run little FTP transfer jobs. Command line FTP scripts work well for this. The login and password can be put in there without risk, because the user can’t do anything but run the little jobs that he’s authorized to run and other users can’t get at his stuff either.
Oh yes, Level 40 for QSECURITY, passwords must be changed every 60 days, tear down the postit notes that are pasted on the side of the monitor, and deactivate device and user profile after 3 invalid login attempts. A little missionary work is probably helpful too, so that users understand that you are protecting their jobs, not making their lives more difficult.
Question Are there problems with having one profile own a lot of objects?
Answer: Beware of having one Profile owning all objects. There is a limit as to the amount of space that the “security table” associated with a profile can occupy. As objects are deleted, their space in this table is not recovered/reused. The only way to recover the space is to “crash” the machine, the IPL will rebuild the table.
Some sites with a VERY LARGE number of objects, have had problems with this – this is NOT an academic issue.
Question: What are some of the pitfalls of using the adopted authority approach (“application only access”) to production files? In this approach, users have no rights to application database files. All programs adopt the authority to access appropriate files, and only authorized users are allowed to execute these programs.
Answer: Here is a short list of pitfalls to avoid;
A) Don’t have one profile own everything on your system. Separate ownership by applications (or some other logical business delineation). This provides for more granularity in your security design, and prevents having one profile own too many objects.
B) Don’t have the same profile own the data and the ‘adopting’ programs. If you do then users will effectively have ‘*ALL’ authority to the entire application. Better to have one profile own the all data and all ‘un-adopted’ program objects. The grant a second profile (the adopter) appropriate (*USE or *CHANGE) rights to the data. Now when users call the adopting program they have *USE, or at the most *CHANGE rights to the data rather than *ALL.
C) Neither of these profiles should have passwords. Their only purpose is to own objects.
D) The profiles should not be group profiles for any system user. You don’t want users to inherit *ALL authority to any of these objects.
E)To restrict access to entire applications, secure at the library level. It’s fast, it’s easy to do (and undo if you must), and it requires little long term maintenance. I’m convinced that overall AS/400 security could improve by a phenomenal percentage if System Administrators would just lock library authority down. *PUBLIC *CHANGE access to a library seems awfully excessive, but you’d be surprised at the number of shops I’ve run across that are configured this way.
The above scheme works well if your users don’t expect to get directly at the data using some AS/400 or PC query tool. If users do use query or other report writing tools, they will need a front end built for them that provides them access to the specific data that they expect to query.
Question: Is there a good alternative to “application only” security?
Answer: Another option that can used instead of, or in conjunction with, the ideas laid out above is to use exit point programs to secure ODBC, FTP, RMTCMD, etc. Exit point programs can control who is allowed to read, update, and even delete files that are accessed from remote systems. There are exit points for Client Access servers (yes, there is even one now for non-IBM ODBC drivers!) as well as for DDM and TCP/IP connections. You can certainly write your own exit programs, but if you’d just like to buy a solution, many vendors sell exit point packages that can handle this for you.
Question: I’d like to set up someone as a security officer, but exclude them from certain libraries (such as payroll). What is the best way to go about doing this?
Answer 1. Does this guy really need *ALLOBJ authority, or can he get by with *ALL authority to select LIBRARIES and FILES?
Utopian Answer: One of my former bosses once said to me, when this issue came up, (paraphrased) “Wouldn’t it be great if we could just post everyone’s salary on the bulletin board? No politics, nothing to hide. You can only do that, though, when noone’s being treated unfairly and noone’s being favored. Unfortunately, that seems never to be the case.”
Answer 2. If you user profile has *ALLOBJ special authority then you cannot restrict access to libraries. Typically a *SECOFR user will have *ALLOBJ.
Here’s what you can do:
- Create a group profile (eg: GRPSEC) as a *SECOFR user class (with *ALLOBJ authority etc)
- Create a user profile (GEORGE) with say the *SYSOPR user class and group this profile to GRPSEC. parameter GRPPRF(GRPSEC).
- Grant private authority to the libraries for GEORGE to be *EXCLUDE. You can leave PUBLIC authority alone.
This will allow George to be a Security Officer with ALL the *SECOFR special authorities, but will restrict his authority to the libraries you choose, even if PUBLIC authority is *USE *CHANGE or even *ALL.
This works because of the sequence that that the authority is checked. I have an old redbook that lists the Authority search order:
USER PROFILE
- Does user profile have *ALLOBJ special authority (In GEORGE’s case …NO)
- Does user profile have explicit authority to the object (This is where we come in. GEORGE is EXCLUDED)
- Does user profile appear on the authorization list of the object.
GROUP PROFILE
- Does group profile have *ALLOBJ special authority.
- Does group profile have explicit authority to the object.
- Does group profile appear on the authorization list of the object.
PUBLIC
- Use the object *PUBLIC authority unless *AUTL is indicated.
GEORGE is EXCLUDED from you sensitive libraries in step 2. Authority
checking then stops.
Answer 3. If you give a user profile *ALLOBJ, it is impossible to keep them out of any library. *ALLOBJ really means All Object. The user can read anything. An enterprising user with just *ALLOBJ can quickly gain any other Special Authority that they desire.
Consider using adopted authority instead to give them the extra authority they need in a tightly scripted adopted authority routine. This will prevent them from getting too much authority all of the time. If you describe why you want to give them this secial authority, someone may have a way to accomplish your goal.
If you must give them *ALLOBJ, don’t give them *AUDIT (or any other special authority they don’t absolutely need). Then audit either their User Profile or the objects that you are concerned about. Tell the user that you have turned on auditing and that any attempt to access the payroll library will result in corrective action. (*SWAT!)
Question: We need to set up a development lib for a contractor how do we protect the rest of our data and programs? (1/2000)
Answer: Use an authorization list, to provide *EXCLUDE authority for the programmer to specified libraries. Although not a perfect fix, it’s cheap and effective.