RVKOBJ/GRTOBJ *exclude with *allobj

[Guest.Visitor]

RVKOBJ/GRTOBJ *exclude with *allobj

Susan, Why do you think they called it "all object" authority? It's not a misnomer... Chris

[nycsusan@hotmail.com]

RVKOBJ/GRTOBJ *exclude with *allobj

What about for objects in my personal test libraries? I don't want ANYONE messing with my stuff accidentally or otherwise.

[nycsusan@hotmail.com]

RVKOBJ/GRTOBJ *exclude with *allobj

It's not a misnomer... ... that's apparently so in this case. I was still hoping I could *EXCLUDE users from my personal stuff. Oh well, everything in life is temporary. My concern is that I have seen the LAN guy (i.e. a network guy with no AS/400 expertise) given the userid's with God authority. This absolutely kills me. In the name of security, the powers that be give someone without a clue about the 400 the ability to do just about anything they wish to. My point is that not always the most experienced types are the ones with access to this authority. This is why I like to exclude everyone from changing anything in my personal libraries.

[Guest.Visitor]

RVKOBJ/GRTOBJ *exclude with *allobj

Chris, I stand corrected. I did set up a user to test with last night and you are correct about the hierarchial checking. I was positive that you could lock a user out by granting/revoking specific authority. Sorry for the bad info. -bret "Munch, munch, munch. Pop! Fizzzzzzz, Slurp...Ahhhh...Nothing makes eating crow more delightful than nice cold one."

[Guest.Visitor]

RVKOBJ/GRTOBJ *exclude with *allobj

Thanks to everyone who responded. Interesting food for thought, particularly for a newbie such as myself. In the end, I deleted the user's *allobj authority and granted specific rights to the needed menus and objects. Cliff

[GlenKerner]

RVKOBJ/GRTOBJ *exclude with *allobj

I think what a lot of people miss is that *ALLOBJ is not the way to make sure a user has access to a application. I have found that in most cases where this question comes up that somebody at one time felt it easier to give everybody or certain groups *ALLOBJ authority instead of creating a proper security scheme. Then they leave and someone takes over, or the big one, or someone does something they shouldn't have. All of a sudden the scramble begins on trying to lock down the system. Any place I work at that I'm the security officer, the first thing I do is evaluate the current security scheme. Revoke *ALLOBJ authority for all profiles that don't absolutely need it (which is 1 or 2) and set up group profiles that will give specific access to applications. The biggest problem seems to be the attitude that IT should have access to everything. I disagree, IT should only have access to view production data & execute programs (in production). A test environment should be set up where they can manipulate data and create/re-create programs. Once these programs and file changes are ready for production they should be move to production with a specific controlled procedure. We have had several threads dealing with *ALLOBJ authority and I'm surprised at the number of environments that have *ALLOBJ on so many profiles. I'm sorry if I sound like I'm on a soap box, but I really don't understand the reason behind granting anybody *ALLOBJ authority. The only profile that should have access to everything is QSECOFR. Maybe it is just that I come from a very security conscious background but I always thought it was basic business security not to allow people to have access to everything. Even software vendors ignore this principle. For example, ShowCase Strategies has a requirement for the server component (running on the AS/400) that requires the profile that starts it to have ALL of the special authorities. This means the job has those authorities because it adopts the authority. Now we have this job that can run any command on the system and access anything on the system. The reality is that the job doesn't need all that authority and it causes a huge hole in security. Special authorities are utilitized way to often as a convenience. It saves time. IMHO the time needs to be taken to fully evaluate the actual needs of a user (or group of users). Bottom line is that if a profile has *ALLOBJ they can see anything. Whether that authority is granted specifically on the user profile or by the group profile(s). This is very dangerous and opens the system to security violations. Anyway, this are my opinions and I will hop off my soap box now.

[J.Pluta]

RVKOBJ/GRTOBJ *exclude with *allobj

A user with *ALLOBJ is a superuser. They have, be definition, rights to the entire system. If you want something secure, keep it off the server. There is NO WAY to restrict someone from seeing your "personal" stuff, nor should there be. A server must be administered by a single entity, and that person must have access to all data on the server. For the AS/400, this is the user with *ALLOBJ authority. In secure environments, only one user profile has *ALLOBJ, and the password for that user profile is kept in a safe available to only the security officer and his designated backup. Joe

[J.Pluta]

RVKOBJ/GRTOBJ *exclude with *allobj

Glen, I agree that IT should NOT have access to production data (for example, financials and sales data). Testing should be done in a test environment with test data. Upon passing unit and system testing in the test environment, it should then be made available to the production staff for acceptance testing (usually by adding a library list with the test programs). Access to production data is through group profiles and/or adopted authority (I won't go into the pros and cons of the two techniques here). Once the test program is passed, it is moved into the production environment and life goes on. Joe

[nycsusan@hotmail.com]

RVKOBJ/GRTOBJ *exclude with *allobj

There is NO WAY to restrict someone from seeing your "personal" stuff, nor should there be. A server must be administered by a single entity, and that person must have access to all data on the server. In secure environments, only one user profile has *ALLOBJ, and the password for that user profile is kept in a safe available to only the security officer and his designated backup. I don't care about the world "seeing" my stuff as long as it's with *USE authority. It's the newbies and the careless people with *CHANGE or higher authority that concern me. I never said that one person (or a well chosen handful of people) shouldn't have QSECOFR authority over the machine. There should always be at LEAST two people who have authority to everything for emergencies and to do "system stuff". My beef is that I have seen shops where *ALLOBJ is granted to: people who don't have a clue about the 400, or to just about anyone who complains about not being authorized to DO something (e.g. CRTLIB). (And that's exactly how I got the authority in my last job, btw!) See Glen's post, he stated it very well, IMO. In a perfect world, and in a good security scheme, only QSECOFR and perhaps a back up (who actually knows the AS/400), would have *ALLOBJ authority. That's a wonderful theory. Perhaps I am unlucky, but I have been in 4 AS/400 shops now (out of 4) that "solve" authority problems (i.e. the inconvenience of being denied access) by blindly granting *ALLOBJ authority to anyone who complains or giving them the password to a special userid that has *ALLOBJ. Even more disquieting is that fact that 2 of those 4 shops have given the virile userids to LAN GUYS who do not know or care about the 400! I can give examples that would send shivers down your spine. As Glen said, rather than review existing security and perhaps giving users the authority that they need, often a short cut is taken and *ALLOBJ auth is granted just to get the complainer out of the manager's cube. It's risky, it's bad, but it happens.

[David Abramowitz]

RVKOBJ/GRTOBJ *exclude with *allobj

Susan Behrens wrote: I don't care about the world "seeing" my stuff as long as it's with *USE authority. It's the newbies and the careless people with *CHANGE or higher authority that concern me. Without *CHANGE authority, it would be impossible for an operator to restore your objects from a backup, should those objects become damaged, or if you otherwise needed to replace your objects with a restored version. There are legitimate purposes for *ALLOBJ authority. Dave

[nycsusan@hotmail.com]

RVKOBJ/GRTOBJ *exclude with *allobj

I wrote: .... It's the newbies and the careless people with *CHANGE or higher authority that concern me. Dave responded: Without *CHANGE authority, it would be impossible for an operator to restore your objects from a backup, should those objects become damaged, or if you otherwise needed to replace your objects with a restored version. There are legitimate purposes for *ALLOBJ authority. I don't believe I stated that *ALLOBJ didn't have a letitimate purpose. In fact, I said my opinion that a carefully selected few NEED it for emergencies and for system manintenance. And where I work, the operators are neither newbies nor careless. They typically don't go hunting around in personal libraries either - unless it's taking up a lot of DASD or something like that. Operations types with *ALLOBJ are not the ones that concern me, and those are the people who perform the tasks in your list, at least in my shops.

[Guest.Visitor]

RVKOBJ/GRTOBJ *exclude with *allobj

David,

>Without *CHANGE authority, it would be impossible for an operator to restore your objects from a backup, should those objects become damaged, or if you otherwise needed to replace your objects with a restored version.<<

Please do not do not take this personal, but that statement is not correct. If someone only has *CHANGE authority they cannot save or restore someone else's objects. A user will need *OBJEXIST authority to an object to save or restore it or they will need *SAVSYS special authority. (They can get the *OBJEXIST authority in several ways, one of which is if they have *ALLOBJ authority.) If the objective is to give an operator authority to save and restore objects then the operator should be given *SAVSYS special authority. This allows then to do the save and restore operations but does not allow then to delete the object, or change the data in the object (by using interfaces like EDTF or STRSEU).

>There are legitimate purposes for *ALLOBJ authority.<<

I agree, but someone who is only an operator should probably never be given *ALLOBJ special authority. Ed Fishel OS/400 Security, IBM Rochester

[Guest.Visitor]

RVKOBJ/GRTOBJ *exclude with *allobj

Ed, My philosophy is that if anybody outside QSECOFR and QSECADM have *allobj authority, it SHOULD be the operations staff. They are the ones who will have to tread new territories (i.e. tapes, devices, libraries, etc.) and will be the ones most likely to run into unexplained situations. I don't need a staff of operators who have to call me or my security administrator to grant authority because they don't have it. In my shop, it is the operators who are responsible for setting up profiles, granting authority and such, but I do maintain *allobj myself. I may not have the security issue many of you have, as our *Secret Squirel* stuff (PAYROLL) is handled by ADP and that info is not on the system. The rest is MFG goop of which the most dangerous thing is a disgruntled salesperson who takes a customer and/or cost/price sheet to a competitor. -bret

[J.Pluta]

RVKOBJ/GRTOBJ *exclude with *allobj

Well, if you're worried about people changing your stuff, then we move to the issue of backing up your own work, even on a daily basis. On any machine I don't have control over (and there are lots - I have a ton of clients), I make it a habit to regularly create a save file of my critical work and FTP it to a secure server. Particularly important information gets burned onto CD-ROM. Not that I'm perfect at it. Even the "secure server" has the potential of going belly-up. I lost two weeks of productive development time because I hadn't properly backed up my Windows 2000 workstation. It's my own fault; I'd gotten lulled into a false sense of security because W2K rarely crashes, and I had mirrored data onto two separate disk drives. Neither one helped when I lost my motherboard and then tried to restore, only to find that I had to reinstall all my software from scratch and that my saves weren't done properly to support a full reinstall. I have learned from that mistake, but by and large I've come to the conclusion that it is completely my responsiblity to take care of backing up my stuff, both on the AS/400 and on my workstation. Joe

[David Abramowitz]

RVKOBJ/GRTOBJ *exclude with *allobj

Hmmmmmmmm. If you have non-admin non-operational types with *ALLOBJ authority in a large shop, that would be cause for concern. Dave