IFS refers to Integrated File System, a component of the IBM i operating system, facilitating stream input/output and storage management similar to personal computer and UNIX systems, while offering a cohesive structure for all information stored within the system. Ensuring IFS security is a primary concern when developing security strategies for IBM i.
One of the significant challenges faced by security administrators is managing security related to the root directory (‘/’). This root directory houses the majority of IBM i products, third-party applications, configuration files, code, and data.
A major concern is that the root directory «/» is publicly accessible, with the default setting allowing full access for public users. Upon installation of a new IBM i operating system, the default permission for root is set to *RWX, which poses a considerable risk and should be modified. The IFS enables users to store and manage various types of data, such as documents, images, program source code, and more. It offers a unified interface for accessing and managing files across different platforms, simplifying the integration of IBM i systems with other systems in a diverse IT environment. Often, the data stored in IFS is sensitive and requires robust security measures.
Virus Scanning for the IFS
Viruses are designed to target specific computer architectures. The unique architecture of the IBM i system significantly reduces the likelihood of a virus being developed to exploit it. Viruses intended for PC environments cannot operate on the IBM i operating system, and IBM does not offer any dedicated Anti-Virus, Anti-Spyware, Anti-Malware, or Anti-Ransomware solutions for this platform. However, if a file infected on a PC is transferred to the Integrated File System (IFS) and subsequently shared with another PC, it can potentially spread the virus to that new machine. Similarly, if a network drive is connected to the IFS, a virus from a PC that can affect files on a network drive may also compromise files stored on the IFS. Nevertheless, the IBM i system does support scanning for malicious activities through third-party software. Users can scan objects within the integrated file system, providing them with the flexibility to determine the timing of scans and the actions to take based on the outcomes. The two exit-points related to this support are:
- QIBM_QP0L_SCAN_OPEN – Integrated File System Scan on Open Exit Program. For this exit point, the integrated file system scan on open exit program is called to do scan processing when an integrated file system object is opened under certain conditions.
- QIBM_QP0L_SCAN_CLOSE – Integrated File System Scan on Close Exit Program. For this exit point, the integrated file system scan on close exit program is called to do scan processing when an integrated file system object is closed under certain conditions.
Note: Only objects in file systems that have been fully converted to *TYPE2 directories will be scanned.
Example for securing a file share directory
Tips to enhance security measures
Consider the following to enhance security measure for Integrated File System.
1. Review File Shares
A systematic review of the file shares should take place on a regular basis. This evaluation is important, as it can greatly lower risk by ensuring that any unnecessary shares in the system are removed.
2. Set shares to Read-only wherever possible
Acknowledging the potential risks associated with write access, particularly in the context of ransomware or malware, it is vital to implement access review processes. The primary goal of these exercises is to lower the risk of security breaches by routinely examining access rights. This involves making educated decisions about who has access to sensitive data and critical resources, and determining whether such access is warranted for each user. This includes root and should be changed to *PUBLIC use only.
3. Do not share the root or /QSYS.lib
Sharing the root directory («/») or /QSYS.lib poses a considerable security threat, especially in the absence of effective access controls. If someone maps to root they can see the entire structure of then system. This practice reveals all files and directories under the root, which is not advisable; therefore, it is better to create specific shares as needed, no higher.
4. Use Authority Collection if have unclear on the usage of shares by users
The authority collection feature is included as part of the core operating system. It operates by collecting data linked to the run-time authority verification processes embedded within the IBM i system. The primary goal of this feature is to support security administrators and application providers in safeguarding application objects with the least amount of authority required for effective operation. Utilizing authority collection to reduce or prevent excessive authority contributes to strengthening the overall security of the objects employed by an application.
5. Restrict server and share access with Authorization list
Starting in IBM i 7.5, user access to IBM i NetServer and specific shares can be restricted by assigning an authorization list. IBM i NetServer now allows assigning an authorization list object to the server and individual shares. The authorization list is used as an extra layer of protection for shared resources. Updating the configuration can be performed through Navigator by changing IBM i NetServer Properties or Share properties or by using the IBM i NetServer APIs. A user must have at least *USE authority to the authorization list to access the server when an authorization list is assigned.
Note: Authorization lists do not restrict access to users with *ALLOBJ special authority. Any user profile with *ALLOBJ special authority will be able to access IBM i NetServer as if there is no authorization list restriction in place. This can be used to create administrative shares that can only be accessed by IBM i administrative profiles by specifying an authorization list that only lists public *EXCLUDE.