|How Did IBM Enhance Security in 7.1?|
|Security - IBM i (OS/400, i5/OS)|
|Written by Pat Botz|
|Thursday, 15 April 2010 23:00|
Some changes have system administrators in mind; others benefit ISVs.
Version 7.1 of the IBM i operating system introduces several not quite jaw-dropping but nonetheless useful security enhancements. ISVs will find certain enhancements particularly interesting, while others will be of greater interest to customer IT shops.
Automated Profile Disablement
For the average customer, the enhancement of greatest interest may be the new "automated profile disablement" feature integrated into user profiles. The system will not allow anyone to log in with a disabled profile, even if the correct password is provided. In previous releases, the only ways to disable a profile were by a user repeatedly attempting to authenticate using an incorrect password or by an administrator explicitly setting a profile's status to *DISABLED.
Similar support has been available in the Security Toolkit functions available on the IBM i since the mid-1990s. But that function, found in the DSPACTSCD and CHGEXPSCDE commands, was provided on top of rather than integrated into the OS. Many customers were not aware it even existed.
The DSPACTSCD and CHGEXPSCDE commands from the security toolkit continue to provide the same function as they always did, but their function is now integrated into the system. You can still delete (rather than disable) an expired user profile, but that function is available only through the CHGEXPSCE command. DSPUSRPRF provides the same information as DSPACTSCD for a specific profile.
All of the user profile expiration information is displayed via DSPACTSCD and DSPUSRPRF. The commands, CHGEXPSCDE and DSPACTSCD, work as they always did but are now tied together, from a code perspective, with the new user profile parms (you can use either). *DELETE is still supported on CHXGEXPSCDE. If you use CHXGEXCPSCDE PAT on a profile and then DSPUSRPRF PAT, you will see the expiration date and option (*DISABLE or *DELETE).
Encrypted Storage Enhancements
Also of potential interest to customers is additional support for encrypted auxiliary storage pools (ASPs). V6.1 introduced software encryption for newly created ASPs. Existing ASPs, however, couldn't exploit encryption. V7.1 allows a customer to turn software encryption on—and off—for existing ASPs, which provides much more flexibility. Encryption keys used to encrypt data on ASPs—and protected by a master ASP encryption key—can also be changed beginning in V7.1. This enables periodic key rotation.
Database Field Procedures
Of particular interest to ISVs and to the more advanced IT shops is a new database feature IBM calls "field procedures." Similar to triggers, they are user programs called during read, update, and insert operations for defined columns in a database table. Field procedures can be used for any purpose; however, they include an extra twist: an internal data space independent of the I/O buffers used for the "external" column data. This will be especially useful for encrypting database fields holding sensitive data.
Field procedures are defined for specific columns using CREATE/ALTER TABLE SQL statements. During CREATE/ALTER TABLE processing, the system calls the field procedure program. The program returns the length of the data to be stored in the internal data space. The internal data length can be longer or shorter than the length of the data in the field itself.
During update and insert operations, the system calls the procedure with the data intended to be stored in the field. The field procedure can return the same or different data back to the system.
During read operations, the system also calls the procedure. The procedure can return the data currently "officially" stored in the field, or it can return modified or completely different data as long as it matches the field definition.
So how would a procedure use the internal data space? That's easiest answered by an example. Assume you have a column in a table defined as 11 characters and intended to hold Social Security numbers. A field procedure is defined for this field. An application inserts a new row with a valid Social Security number, say, 123-45-6789. The system calls the field procedure, passing it (among other information) the data provided by the application to be stored in the field. The field procedure uses an encryption package to encrypt the Social Security number. The encrypted string is 16 bytes long. The procedure stores the encrypted value in the internal data space. It returns the string ***-**-6789 to the system, and this value is stored in the field. Note that this means that fields don't have to be redefined to accommodate encrypted versions of any data not matching the field definition.
During read operations, the system calls the procedure with the data "officially" stored in the field. In our example, the procedure receives ***-**-6789 from the system. The procedure, however, decrypts the data stored in the internal data space (yielding 123-45-6789) and returns this value to the system, which, in turn, returns this value to the caller.
The Display File Field Definition (DSPFFD) command shows whether a field procedure is defined for the field or not. Queries of the DB Cross-Reference Catalogs will also show defined field procedures.
The SQL Programming Guide offers a sample field procedure and discusses usage and restrictions.
TCP/IP Transport Security Extensions
Since V3R1, the Telnet server has provided a "connection time" exit point. The system passes TCP/IP connection information (e.g., addresses, ports) associated with the accessing (i.e., remote) system and the local system involved in the potential connection. Customers and vendors can build exit point programs that decide whether to allow or deny the connection, based on the information passed to it. This capability was only available to a few system-provided TCP/IP applications.
In V7.1, IBM provides exit point support for the TCP/IP accept(), connect(), and listen() APIs. These exit points allow the same connection time function as is available for Telnet to any arbitrary user-written TCP/IP application.
SSL Support for IBM i Telnet Client
The IBM i Telnet server has long supported SSL connections. However, the Telnet client on the i has not been able to use SSL connections. That is no longer the case in V7.1. New parameters have been added to the Telnet command to allow SSL connections.
Digital Certificate Manager (DCM) is used to associate a client certificate with the Telnet client. This means that a single certificate is used for all Telnet-over-SSL connections originating on the i. This isn't much of a restriction since most Telnet servers only require a valid certificate from a trusted CA and don't use certificates for client-side authentication.
This support is also PTFed to V6.1 and V5.4, although it is enabled through environment variables. By setting the QIBM_TELNET_CLIENT_SSL environment variable, you can force everyone who uses the Telnet client to use SSL connections or you can turn it on for specific jobs.
IBM also added a new encryption mode option, AES-XCBC-MAC, for VPN and updated SNMP to V3 in V7.1.
Something for Everyone
The new field procedure support is probably the biggest security enhancement in V7.1. But the automated profile disablement support might be the most widely used new security function in the release. Given the collection of security enhancements in V7.1, I suspect a lot of customers, Business Partners, and ISVs will be able to find something valuable in the bunch.
|Last Updated on Thursday, 15 April 2010 16:20|