|
||
October 3, 2012 - Vol 2, Issue 17
|
||
|
||
|
Feature Article
Avoid Unsanctioned 'Drive by' Access to IBM iBy Dan Riehl Most of us run IBM i Access for Windows. That's the newest name for what we used to call PC Support, Client Access and iSeries Access. You probably use the Personal Communications PC5250 emulation software to provide your workstation sessions. You may also use the IBM i Navigator (Operations Navigator, iSeries Navigator) portion of IBM i Access for Windows. There are several IBM supplied applications that are installed on your PC when you install IBM i Access for Windows. Included in these additional applications are the Remote Command facility, the ODBC Driver and various File Transfer programs and Service utilities. One critical piece of software that is installed is the command interface to Set or Flush the Signon Server cached User IDs and Passwords, which is the topic of our discussion here. When you run IBM i Access functions on your PC that require communications with the host, you must first authenticate to the host. To accomplish this authentication, IBM provides the Signon Server GUI window where you provide your credentials(i.e. UserID and Password) as shown here. Once you have successfully authenticated, your PC provides an open session to access the IBM i without any further authentication! You can transfer files, run remote commands, examine spooled files, and more.. . without providing your logon credentials again. So, do you shut down your PC, or flush your cached credentials when you leave your desk? Or, as most, do your leave the session open, thus allowing unsanctioned access to the IBM i for anyone that happens to 'Drive-by' your unattended PC? |
|
In This Issue
Quick Links
Thank You! To Our Great Sponsors
Platinum Sponsor |
IBM i Security and Audit ResourcesIBM i Security Videos from SecureMyi.com SecureMyi Newsletter Home and ArchivesSearch Security Site for IBM i and i5/OS IBM i Security Reference - IBM i 6.1 IBM i Security Reference - IBM i 7.1 QAUDJRN Audit Types By AUDLVL 6.1 QAUDJRN Entry Type Record Layout 6.1 RedBook - Security Guide for IBM i 6.1 PCI SSC Data Security Standards |
|
IBM i Security News Bytes
Linoma Announces Version 3.0 of GoAnywhere Services IBM i Security Calendar of Events
|
|
|
|
||
Security Shorts -
By Dan Riehl A popular misconception held by many people is that if a library is secured as *PUBLIC AUT(*USE), then this library authority provides Read-Only access to the files that reside in the library. For most of us who read this newsletter, we know that this is not true. Here are the rules for library authorities. *EXCLUDE AuthorityIf a user has *EXCLUDE authority to a library, they cannot access the library, nor can they access the objects within the library. *USE AuthorityIf a user has *USE authority to a library, they can access the library, but cannot change attributes of the library, such as the library text. The user cannot add new objects to the library. When it comes to accessing the objects within the library, the object authority is the determining factor. For example, if a user has *EXCLUDE authority to a file in the library, they cannot access the file. If a user has *USE authority to a file in the library, they have read-only access to the file. If the user has *CHANGE authority to a file, they can open the file for update and manipulate the records in the file (add, change, delete). If the user has *ALL rights to the file in the library, the user may perform all operations on the file including deleting the file. Yes, that's right. If a user has *USE authority to a library, the user can delete an object from the library if the user has *ALL authority, which includes *OBJEXIST authority to the object. *CHANGE AuthorityIf a user has *CHANGE authority to a library, they can access the library and can change some attributes of the library. Changes to some attributes require the additional *OBJMGT(Object Management) authority to the library. All of the same object rules are in effect as when the user has *USE authority to the library, but there is one big difference. If a user has *CHANGE authority to a library, they can create new objects in the library. That is the only real difference between *USE and *CHANGE authority to a library. If you have *CHANGE authority, you can add new objects. *ALL AuthorityIf a user has *ALL authority to the library, the user can access the library, and may even be able to delete the library and all the objects within the library. However, if the user does not have *ALL authority, or a mixture of *OBJEXIST and *OBJOPR authority to the objects in the library, the user cannot delete those objects and therefore cannot delete the library. If a user has the authority to delete all the objects in the library, then the library itself can be deleted. All of the same rules apply to object access as when the user has *USE or *CHANGE rights to the library. What about *ALLOBJ Authority?When dealing with library and object authorities, you always have to take into account that some user profiles have *ALLOBJ special authority. When a user has *ALLOBJ special authority, there are no restrictions on accessing objects in your user libraries. A user with *ALLOBJ special authority can read, change and even delete any object in any user library on the system. (Note: There are some objects that may not be deleted even by a user with *ALLOBJ special authority. For example, user profiles cannot be deleted by an *ALLOBJ user, unless that user also has *SECADM special authority.) |
Sponsored Links
IBM i, iSeries and AS/400
|
|
|
||
Send your IBM i Security Related News and Events! Advertise in SecureMyi.com Security Newsletter Copyright 2012 - SecureMyi.com, all rights reserved SecureMyi.com | St Louis MO 63017 |