Getting Started with IBM i Security: Integrated File System (IFS)

All trademarks and registered trademarks are the property of their respective owners.© HelpSystems LLC. All rights reserved.
Getting Started With
IBM i Security:
IFS Security

HelpSystems Corporate Overview. All rights reserved.
ROBIN TATAM, CBCA CISM
Director of Security Technologies
952-563-2768
robin.tatam@helpsystems.com
Your Speaker

• Premier Security Products (globally-recognized “PowerTech” brand)
– Represented by industry veteran, Robin Tatam, CISM
• Comprehensive IBM i Security Services
– Represented by industry veteran, Carol Woodbury, CRISC
• Member of PCI Security Standards Council
• Authorized by NASBA to issue CPE Credits for Security Education
• Publisher of the Annual “State of IBM i Security” Report
About HelpSystems’ Security Investment

What Is The Mysterious IFS?

Independent Front
Suspension
Indian Fertility Society
Initial Flight Screening
Initiative on Financial
Security
Institute for Fiscal Studies
Insurance and Financial
Services
Intensive Freshman Seminar
International Financial
Statistics
International Food Standard
Integrated Forecast System
According to Wikipedia, it can be many
things to many people:

Integrated File System
Integrated File System - on IBM midrange & mainframe
systems (e.g. OS/400, MVS, VM/CMS), the POSIX
compatible file system provided by the operating system, as
opposed to the traditional non-POSIX file system it also
supplies.

• Added to OS/400 in V3R1 in 1994
• Integrates IBM i with UNIX, Windows, and others
• Directory structure much like a PC
• Provides access to data stored on integrated servers,
or on other remote IBM i servers
• Contains several pre-defined file systems:
– All contained within a single root directory
– Each with their own limitations and rules

Contrary to popular belief, it was not an add-on to
the existing file structures, but rather encompasses
ALL of the file structures. This includes those that
pre-date the IFS such as:
Native Libraries QSYS.LIB
Documents and Folders QDLS

We ALL technically use the IFS as it encompasses
QSYS.LIB
Some other common uses of the IFS include:
• Integrated PC servers (Intel processor)
• NetServer (Explorer access to the IFS)
• CD images for unattended installation
• PASE environment for UNIX applications
• IBM i Access (Client Access) & Navigator executables
• Apache HTTP server
• Tomcat application server
• WebSphere application server
• Lotus Domino
• Digital Certificate Manager
“I’m Not Even Using The ISF, I mean IFS!”

IBM i ships with its public access default to the
IFS set to:
Native objects = *CHANGE
IFS root folder = *RWX
plus all object authorities
(aka *ALL)
TIP: This should be changed ASAP!
It’s Already Secure, Right?!”

Organizations often place
tremendous trust in the
people accessing their
servers.
Authorized users usually
have privileges far in
excess of any business
requirement.
“But Bill Has Worked Here for xx Years!” (insert big number)

According to the “State of
IBM i Security Study,” most
organizations still base their
security on lack of user
knowledge or malicious intent.
• Average of 147 users with
*ALLOBJ special authority
• Average of 76 enabled profiles
with default passwords
“But Bill Has Worked Here for xx Years!” (insert big number)

Lots of people have skeletons in
their closet!
The cold reality of an economic
downturn may cause (normally)
trustworthy users to act out of
desperation.
And there are vices like gambling
and drugs that often influence
ethics.
And, of course, anyone can make
a legitimate mistake!
But How Well Do We REALLY Know Him?

IBM i vs. Unix vs. PC

In IBM i, every object has data authorities and object
authorities.
Data authorities consist of:
Read, Add, Update, Delete, and Execute.
Object Authorities consist of:
Opr, Mgt, Exist, Alter, and Ref.
IBM i authorities (data and object) are typically assigned
using one of four IBM-supplied templates:
*USE, *CHANGE, *ALL, and *EXCLUDE
Object Authority vs. Data Authority

• Data Authorities
– *READ - Required to read the object
– *ADD, *UPD, *DLT - Required to change the object
– *EXECUTE - Required to run a program or find an object
• Object Authorities
– *OBJOPR - Required to operate on data (set if there are any data authorities)
– *OBJMGT - Required to move, rename, or work with permissions
– *OBJEXIST - Required to delete, save, and restore the object
– *OBJALTER - Database authority
– *OBJREF - Database authority
• IBM-Supplied Templates
– *EXCLUDE - Specifically denies access to the object
– *USE - *OBJOPR and *READ and *EXECUTE
– *CHANGE - *OBJOPR and all data authorities
– *ALL - All data and object authorities
IBM i Authorities

The IFS security model is a unique combination of
IBM i authorities, PC file properties, and Unix file
permissions.
IFS
Security
IBM i
Authorities
IBM i Authorities

For IFS objects, ‘Opr’ (Object Operational)
authority is considered a data authority and NOT
an object authority.
Object Authority vs. Data Authority

In Unix terminology, we secure files and directories
using a combination of Read (*R), Write (*W), and
Execute (*X) permissions.
As with *USE, *RX provides Read and Execute data
authority and no object authorities (except ‘Opr’ as noted
on the prior slide).
As with *CHANGE, *RWX provides all data authorities
and no object authorities (except ‘Opr’ as noted on the
prior slide).
There’s no
UNIX
equivalent
of *ALL
*CHANGE
*USE
UNIX Permissions

PC properties, such as ‘read-only,’ are another
layer of protection against object abuse. Even
*ALLOBJ users are unable to delete a file
marked as read-only.
Other file properties include:
– Need to archive (PC and system)
– Hidden file
– PC system file
PC Properties

PC properties can be viewed
and altered using:
– IBM i’s CHGATR command
– Navigator for i properties
– Windows Explorer Properties
(NetServer)
– DOS “attrib” commands
PC Properties

IBM i supports a check out/check in capability that
restricts certain functions to the user that has
checked out the file.
This process can be performed via:
– Navigator for i
– Check Out (CHKOUT) Command
– Check In (CHKIN) Command
IBM added subtree support in v6.1 so that users can now check
out/in entire folders or directories.
PC Properties

Under the covers, all IFS objects are still IBM i
objects and therefore have IBM i authorities.
Actions must still meet the requirements set forth by
IBM i.
For example:
To delete a stream file, you must have *OBJEXIST
authority. This is an object authority that’s not
associated with *R, *W, or *X and must be granted
separately, or inherited from the directory.
IBM i Authorities

Batten Down The Hatches

With the exception of ‘root,’ most IBM directories are
already configured with the appropriate security
settings. Vendor or user directories may not be.
It’s easy to “over secure” the IFS due to the nature
of nested directories and unfamiliar security
mechanisms.
Plan carefully and make detailed notes of changes so
that you can always revert back if there is a
problem.
It All Starts At The “Root”

The ‘root’ (/) folder ships with powerful
*PUBLIC permissions:
DTAAUT(*RWX)
OBJAUT(*ALL)
Instead, consider assigning the following:
DTAAUT(*RX)
OBJAUT(*NONE)
Do NOT set
*PUBLIC to
*EXCLUDE
Restrict The Right To Write

A user requires *X authority to each directory
in the folder structure. However, without *R,
they cannot see the contents of the directory.
Consider whether a user should be able to
access (read or write) the contents of the
parent folder(s) or just simply navigate to
a subfolder.

Consider giving users their own directory under
‘/home’:
Set DTAAUT(*X) for *PUBLIC on ‘/home’
Set DTAAUT(*EXCLUDE) for *PUBLIC on all user
directories
Set DTAARA(*RWX) for the user on their own
directory (e.g. ‘/home/rtatam’)
This enables a user to access his or her own directory, but not
touch (or see) other users' directories.

IFS Permissions can be assigned through a traditional
green screen interface using:
WRKAUT, CHGAUT, DSPAUT
Or through the Navigator for i interface.

Most organizations don’t need users to be able to
access the native libraries and objects from remote
clients like Access for i, NetServer, and Java
Toolbox.
Fortunately, IBM provides an authorization list to
control who can access QSYS.LIB:
Authorization List QPWFSERVER
Default *PUBLIC *USE
Recommended *PUBLIC *EXCLUDE
Warning: Not effective against *ALLOBJ users!
Restrict Access to Qsys.lib

Many organizations make their IFS accessible to
client users by establishing unnecessary file
shares. Use Navigator for i to:
– Review & eliminate unnecessary file shares
– Make shares “read only” when possible
– Grant only *X permission to folders in shared
path
– Do NOT share the ‘root’ (/) folder
Don’t give
every
user access to
IBM i Nav
Manage File Shares

Similar to auditing of IBM i objects, the IFS also
supports event auditing.
– Ensure QAUDCTL system value includes the value
of *OBJAUD to “turn on” object auditing.
– Use CHGAUD command to specify the desired level
of auditing for each object or directory.
Deploy exit
programs to
better
audit IFS events
Audit IFS object Access

As with libraries, each directory has a Create
Object Auditing (CRTOBJAUD) value to
designate the auditing default for the contents
as they are created.
You need audit (*AUDIT) or all object (*ALLOBJ)
special authority to see the assigned auditing
setting:
*SYSVAL, *USRPRF, *CHANGE, *ALL, *NONE
Audit IFS object Access

IFS commands are (by default) secured from limited
capability users - LMTCPB(*YES).
Command-capable users might have access to the
following powerful native IFS commands:
Command(s) Shipped *PUBLIC
WRKLNK *USE
MD | MKDIR | CRTDIR *USE
RD | RMDIR | RMVDIR *USE
CD | CHGDIR | CHGCURDIR *USE
Secure Native IFS Commands

Other powerful IFS commands to be guarded
include:
CPYTOSTMF Copy to Stream File
CPYFRMSTMF Copy From Stream File
CPYTOIMPF Copy To Import File
CPYFRMIMPF Copy From Import File
WRKAUT | CHGAUT Work | Change Authority
CHGOWN Change Owner
SAV | RST Save | Restore
Secure Native IFS Commands

The IFS does NOT support the adoption of authority.
This can represent a challenge to applications that
are built on a foundation of adoption.
Profile switching IS supported in the IFS, so use the
IBM-provided APIs or a
tool like PowerTech Authority
Broker to temporarily alter
user privileges—
akin to Superman’s phone booth.
Authority Adoption and Profile Switching

(Overly)
Privileged
Users
Permissive
Public & Private
Authority
Your
Security
Security Is At The Mercy Of Multiple Controls

Exit points enable a process to be
temporarily “interrupted” by a user-
written program.
There’s an exit point for FTP and
ODBC, and yes, IFS!
(Strongly) Consider implementing an
exit program to audit and control
actions affecting the IFS.
Another Great Reason For An Exit Program

The IFS exit point provides easy-to-interpret interrogation
and supplemental control of user activities, including:
• Allocate conversation
• Change file attributes request
• Create stream file or directory
• Delete file or directory
• List file attributes (or directory contents)
• Move file
• Open stream file
• Rename file
Works with
*ALLOBJ
users

An example of recording user activities within the IFS
using an exit program:

Don’t Overlook Disruption By Viruses

Long thought to be immune to
the virus threat, IBM i can
actually act as the source of
virus problems on your
network.
While malicious code can
reside natively, viruses can
often impact the IFS.
A Virus On IBM i? Oh, Surely Not!
And don’t think they can’t rename, delete, or encrypt native objects!

Image Catalogs,
NSF Mounts, UDFS Mounts
Business Partners
CDs
High Availability Systems
Backup Tapes
Mapped Drives
FTP
How Viruses Can Spread To and From IBM i

How Viruses Can Spread To and From IBM i

IBM i added system values (QSCANFS, QSCANFSCTL)
to interface with a commercial scanning solution for:
• On-demand scanning
• Open/close scanning (V5R3+) via exit point integration
QIBM_QP0L_SCAN_OPEN – IFS Scan on Open
QIBM_QP0L_SCAN_CLOSE – IFS Scan on Close
• Object integrity
• Alerting
Check out
StandGuard
Anti-Virus
Protect & Immunize Objects With Commercial Anti-Virus

Scanning from another server is BAD for several
compelling reasons:
• Requires a read/write share to ‘root’ to search and
cleanse all directories
• Requires an *ALLOBJ profile to effectively run the scan
• Network bandwidth is consumed by hundreds of
thousands of objects being moved around
• Transmits all objects in clear text
• The operating system remains unaware that a file is infected
But Don’t Scan From The Network!

…Or You Might Make The Situation Worse!

• Determine what applications are using the IFS (Exit program)
• Understand how security works on the IFS
• Establish security for top-level folders like ‘root’ and ‘/home’
• Secure access to /QSYS.LIB
• Monitor and protect file shares (don’t share ‘root’) and make them
read-only whenever possible
• Audit and alert on user activities using an exit program
• Protect from viruses
• Test your security!
Summary Of Today’s Lesson

Run a HelpSystems Security Scan

Security awareness among IBM i
professionals is generally low.
IBM i awareness among audit
professionals is even lower.
Some of the most valuable data is
stored on a Power Systems server
(iSeries, AS/400).
Most IBM i data is not secured and
the users are far too powerful.
Most data is easily accessed via PC
interfaces with little-to-no oversight
The Perfect IBM i Security “Storm”

Free Download:
2016 State of IBM i Security
https://www.mc-store.com/products/ibm-i-security-
administration-and-compliance-second-edition
Learn More About IBM i Security

Question And Answer

Register Online at
http://www.helpsystems.com/getting-started-security-series
See you on July 26th at 12 noon CST to discuss Public Authority
Final Episode Coming Soon!

Getting Started with IBM i Security: Integrated File System (IFS)

More Related Content

What's hot (20)

Similar to Getting Started with IBM i Security: Integrated File System (IFS) (20)

More from HelpSystems (20)

Recently uploaded (20)

Getting Started with IBM i Security: Integrated File System (IFS)