System iNetwork Head Nav Subscribe Log In Contact Us Advertise User login Username: * Password: * Request new password

Search Primary links Forums Archives Code Blogs Podcasts Webcasts e-Learning Guides Newsletters About Us Contact Us About the Network Tech Editor Profiles Editorial Calendar Writers Kit Advertise Join Network Categories RPG Programming Other Languages Application Development Database/SQL Availability Security Systems Management Networking IT Mgmt/Careers Site Links Solutions Store Events UK Centre Jobs System iPortal Home Content The Danger of Unsecured User Profiles Article ID: 56894Posted July 2nd, 2008 in Systems Management Securing a system for your organization can be a daunting task, drawing on reso urces from every corner of the enterprise. If you happen to have a knowledgeable and experienced System i security administrator, count yourself among the very fortunate few. These folks are quite scarce, and with the graying of our technic al ranks, they are getting scarcer day by day. Over the years, I have been retained by many large and small organizations to pe rform System i security assessments -- my job was to tell them what's wrong and how to fix it. There is one particular security risk that I find to be ubiquitou s in both large and small organizations. In this article, I'll spell out this ri sk and tell you how to fix it. The Risk Defined Let's say I'm a programmer or contractor at your place. I want to look at or do things that I'm prohibited from doing by i/OS security, such as look at the prod uction payroll file or worse yet, modify the records in that file. So, since my user profile is prohibited from even looking at the file, I need to borrow/steal

the authorities of some powerful profile, maybe QSECOFR. At security level 30, this can be painfully easy, at level 40, maybe a bit more difficult, but probabl y doable. So, how does one borrow or steal a user profile? Without providing a hacker's gu ide to the i/OS, let me just mention a few things to be aware of. If I have even *USE authority to someone else's user profile, I can run jobs as that user. Und er the i/OS, user profiles are created with the default public authority of AUT( *EXCLUDE), and this is what you want. If you have carried user profiles from far in the past, it is probable that you have many user profiles that are not secur ed with AUT(*EXCLUDE). If the public authority on a user profile is AUT(*USE) or better, you are at risk for user profile borrowing. You see, if I have *USE authority to another user profile, that means I have the rights to use that profile to perform work on their behalf. I can submit batch jobs for them or dynamically swap my job to run under their profile in place of mine. In doing so, I temporarily pick up and use their authorities. If I have *U SE authority or higher to another profile, I do not even need to know their pass word to perform work on their behalf. To find these offending profiles, you can use the PRTPUBAUT(Print Publically Aut horized Objects) command. You can also use the DSPOBJAUT(Display Object Authorit y) command to see detailed authorizations. To fix this problem, check your user profiles to make sure that user profiles ar e secured by AUT(*EXCLUDE), and that no unneeded private authorities exist to th e profile. If they are not secured correctly, then change the authority to AUT(* EXCLUDE), and remove any unneeded private authorities. Under system security level 30, another easy user profile borrowing method is av ailable, which is widely known and has been published by System i trade magazine s. It is also documented in the iSeries Security Reference. This method of borro wing a profile is one of the many reasons to run your system at security level 4 0 or 50. This exposure is found when running a job using a job description that specifies the name of a user profile in the USER parameter. When a user runs a job with o ne of these job descriptions, the job can run under the authority of the named u ser, not under the authority of the submitting user. For example, I submit a job using a job description that specifies QPGMR as the USER parameter. When the jo b runs, it runs under the authority of QPGMR, and not my submitting user profile . The problem at security level 30 is that I do not need any authority to the user profile named in the job description -- all I need is *USE authority to the job description itself. This hole is fixed under security level 40 and 50, in which I need authority to both the job description and the named user profile. Other Considerations There are a few IBM profiles for spooling and other internal functions that shou ld not be messed with. Other IBM profiles like QSECOFR, QSYSOPR, QSRV, QSRVBAS, QPGMR, and QUSER should be *PUBLIC AUT(*EXCLUDE). In some i/OS configurations, the applications have been implemented in such a wa y that *USE authority to certain profiles is required to make certain jobs run. If you have these implementation issues, test before you implement any changes t o profile authorities, with a view to removing any requirement to use another pr ofile. Bookmark/Search this post with:

Login to post comments Email this page Printer-friendly version Related Links Password Change Blocking for V5R4 and Earlier Beware of Registered Exit Programs - Yours and Theirs QPWDCHGBLK Revisited for V5R4 Password Change Blocking Retrieve CL Command Attributes with RTVCMDINF i/OS 6.1 Password Rules System Value (QPWDRULES) ProVIP Sponsors ProVIP Sponsors

Featured Links