AIX Security Tools

AIX Users’ Group – Thurs. June, 19 2008

Marija Mijalkovic
Power Systems Technical Sales
IBM Canada
marija@ca.ibm.com
 Agenda

 Introduction
 AIX Security Expert (aixpert)
 Secure by Default (SbD)
 File Permission Manater (fpm)
 Trusted Execution (TE)
 Role Based Access Control (RBAC)
 Encrypted Filesystems (EFS)
 Trusted AIX (MLS)
 Other new features

2
 Introduction ...

 Computer security ... Dynamic and changing world

 Enterprises must be diligent to integrate many mechanisms to address
threats.
 Have to understand strengths and weaknesses, value of assests and
source of threats.
 OS is the foundation upon which the rest of the software stack builds
its security
 Historically AIX has provided solid security; new features only build on
that.
 A complete security model is a combination of technologies, business
practices and social engineering!

3
 AIX Security Features – What Do I really need?

Feature Who Should Use it

AIX Security Expert EVERYONE!!! Hardening scripts can be added as additional rules
and invoked by AIX SE.

Secure By Defualt Users who want minimal filesets installed and want strict control on
what is added to the os. Network connectivity is disabled.

File Permission Mgr If you want to minimize programs with setuid bits on.

Role Bases Access Organizations with many admins who don’t want to give them all root
Control access and abilities.

Encrypted Filesystem Customers who want extra protection by encrypting files.

Organizations required by legislation to encrypt sensitive data.

Trusted Execution Customers who want integrity checking on AIX os files and other
customer specific files.

Workload Partitions Those who want added system isolation for applications/
environments; prevent them from interfering with one another

Trusted AIX Customers whose data has different security classification levels and
want to remove the concept of an all powerful root id.
Long Passphrase Support Organizations that want to use longer passwords.

5 © 2008 IBM Corporation

 AIX V6.1 Security Expert
How it can help? What is it?
A centralized security
Go Green & Save
management tool that can
control over 300 security settings
from a single console
Manage Growth,
Complexity & Risk Administrators can start from a
“Low”, “Medium”, “High” or
Can reduce the cost and complexity of security
administration by allowing federated “Sarbanes-Oxley” security
management of security profiles across multiple template and customize settings
servers to met business requirements
Enables a more secure IT infrastructure by
reducing the effort of maintaining system Security settings can be
security exported and imported as a
“Check” functionality can provide additional security profile to multiple
security by validating that the security profile for systems
each system matches the actual security
settings
On AIX V6.1, security profiles
can be stored in an LDAP
Realize Innovation
directory for ease of distribution
Allows for new ways to efficiently manage AIX Security Expert was first
security across multiple AIX systems
included in AIX V5.3 TL5

6 © 2008 IBM Corporation

AIX Security Expert (aixpert)
 Introduced in AIX 5.3TL05 (53H)
 Standardized Security Hardening Tool for AIX
 Before settings via commands and SMIT panels
► Admins hardened systems with home grown scripts
 Provides consistent view of a system's security configuration
► TCP/IP
► IPSec
► Auditing
► Logging
► Weak Password Checking (root only)
► File Permission Manager (s-bits)
 Security Rules defined in XML via GUI
► check box style settings
► can be stored centralized in LDAP repository
► one template can be deployed on many machines

7
 AIX Security Expert (aixpert)
 Standardized security settings invoked early in boot, before network vulnerability
 undo option (reset, recursive)
 Consistency checking – aixpert command builds file that can be used to check
system settings at a later time
 Stringent checks of weak root passwords
► dictionary checks (US English is provided, others can be created)
► Popular feature: default password rules based on industry best practices
 Previewing and audit logging now supported
► writing rules and policy to a file first, without altering the system
► any change made is logged to the audit subsystem, when enabled
 Be careful when applying security level "high"
► telnetd and all r-cmds get disabled
► direct root login gets disabled (local and remote), enforcing 'su'
► strong password rules disable current root pw if it's too old

=> don't lock root out by accident!

8
 AIX Security Expert Hardening Groupings
Policy Grouping Description
Password Aging, lengh, reset, expiration and valid characters

/etc/inetd.conf Disables programs such as tftp, telnet, UCP echo, rshd, and rexd

/etc/tcpip settings Disables many TCP apps in high security

Setuid Policy Removes setuid bits with fpm

/etc/inittab Disables programs like qdaemon, lpd, and piobe

Audit Policy Enables audit if not running

usr/group passwd def Passwords must be set and inobvious

Network Security Port scan detection and installs ipsec

SOX-COBIT config assist Sets policy to improve record keeping for audits

Password Checking Stringent dictionary checks for eliminating weak passwords

Check settings at a later Verify that the initial settings are still valid
time
9 © 2008 IBM Corporation
 Secure by Default (SbD)
 Installation option
 SbD is new default security option
► Installs a minimal set of software
► Does not allow network programs to be active before os is hardened
► Deletes components that use weak authorization (bos.net.tcp.client/server)
and runs AIX Security Expert to apply hardening for level "high"
► Admin has to go back and install software on as-needed basis
 "Bottom Up" Approach
► Reverses traditional "Top Down" approach of full install followed by
hardening
 Thorough planning strongly suggested
► Can all applications' requisites be fulfilled by this install template?

10
 Secure by Default (SbD)

Traditional Approach
Hardening
Process
Reduced AIX
Full AIX Install
Capabilites

SbD Approach

Explicitly install
and enable whats
needed Enhanced AIX
Minimal AIX Install
Capabilites

11
 File Permission Manager (fpm)
 New command fpm to reduce setuid and setgid binaries on AIX
► Best Practice for reducing trojan horses
► AIX has been around for a long time – setuid bits on many system programs has
not been modified; tool replaces the need for customers to write their own scripts
to reduce setuid and setguid programs
 Stand-alone tool, backported to recent AIX 5.3 and 5.2 TLs
 Using the tool
► Removes setuid and/or setgid bits on programs owned by privileged users
► Creates logfile of prior permissions for selective and recursive rollback / undo or
default/factory settings
► fpm –l low/med/high for desired environment
► fpm –l default to restore default settings
► List of bits removed is stored in /usr/lib/security/fpm/data/xxx_fpm_data
► To create custom list of files modify
/usr/lib/security/fpm/custom/xxx_fpm_data

12
 Trusted Execution (TE)
 Signature Based Operating System Integrity Verification (SHA-256)
► create signature database at install time – Trusted Signature Database TSD
► verify system state by comparing important file attributes with TSD
► Uses secure hash algorithm with 256 bit key SHA-256 to calculate signature
► offline, e.g. check everyday through a cron job (much like 'tcbck')
► Run time, i.e. integrity checking at program execution
► system and customer specified files
► Replaces Trusted Computing Base (TCB)
 Policy-driven
► Monitor all executions and loadings of files listed in signature database  
► Lock the signature database so even root cannot write to database
► Lock all "trusted files" to prevent alteration

 Single command: 'trustchk'

13
 Trusted Execution (TE)
 TSD is a stanza file; Add entries to it with trustchk –a
► After all changes are made, put TSD in lockdown mode; to get out of it reboot is
necessary
 Types of Files to keep in TSD
► Kernel and kernel extensions
► All setuid root programs
► Any program run only by root
► Important config files
► Any program that may alter system config files
 All system files of this type are put in TSD by default; customer created files
of above type should be added
 Will block attemps to execute malicious code and important system file
tampering (trojan horses)

14
 Trusted Execution (TE)

System Integrity Check Run Time Integrity Check

**Install Time population**

Executable/
Signature Certificates Module
Database Database

Integrity Checker
Tool
vs. Calculate
Hash
Hash/
Signature
Database

System Integrity Status Policy Engine

Eg: Disallow loads on non-match
Trojan Horse Detection

Memory

15
 AIX V6.1 Role Based Access Control (RBAC)
How it can help? What is it?
A new capability of AIX V6.1
Go Green & Save
AIX that allows privileged
Resources
Users Roles
administration tasks to be
delegated to non-privileged
DBA users
Manage Growth,
Complexity & Risk
PRINT
Access to system resources are
associated with roles that are
Can reduce the cost and complexity of security
administration by allowing secure delegation of assigned to non-privileged users
administrative tasks to non-privileged users BACKUP
Many roles are predefined
Enables a more secure IT infrastructure by
reducing the need for so many privileged
which can reduce the effort of
administrators implementing RBAC
Assigning roles to programs can reduce the
need for security exposures such as the use of
Roles can also be associated
setuid for programs with programs

Realize Innovation

Allows for new ways to delegate administration

duties between system administrators and non-
administrative users

16
 Role Based Access Control (RBAC)

 The ancient problem: Unix and the root user

► Unique user in the operating system with all privileges
► System administration tasks
● Install, backup/restore, user management, etc.
► Root necessary, but security concerns
● e.g. hijacking of process owned by root
► Reliance on a single trusted admin
● Otherwise passwords need to be shared => security issue
 Before
► DAC – discretionary access rwx

 RBAC requires planning but is a lower risk strategy!

17
 Role Based Access Control (RBAC)
 Starting with AIX 4.2 rudimental (legacy) RBAC controls were implemented
using "authorizations" (s-bits) and role verification to de-escalate root's
singular power
► new roles could be created but not new authorizations
 AIX 6 introduces Enhanced RBAC with fully customizable authorizations
maintained in separate (ASCII) files
► all files reside in /etc/security
► accessed directly by commands, SMIT
 Mode selectable through system configuration, reboot required
► chdev -l sys0 -a enhanced_RBAC=true (default)
► enhanced_RBAC system environment variable
 LDAP and WPARs supported
 The end of 'sudo' ?

18
 Role Based Access Control (RBAC)

 Authorizations
► Mechanism to grant access to commands or certain functionality.
► System defined or user defined

 Roles
► A group of authorizations that can be assigned to a user.
► Users switch into and out of roles to perform
perform priviledged operations

 Privileges
► Process attribute that allows process to bypass a security restriction.

 Authorizations vs. Privileges

► Auths exist only outside of kernel, Privs only inside
► Auths enable access to commands, Privs enable execution of single
functions
► Authorizations are the keys that give access to priviledged commands

19
20
 RBAC Infrastructure
 Infrastructure to create and track authorization, roles and
priviledges are stored in separate databases
► Authentication DB
► Role DB
► Priviledged command DB
► Privileged device DB
► Privledged File DB

21
 Role Based Access Control (RBAC)
 Authorizations are defined locally in /etc/security/authorizations
 Authorization name may be up to 63 printable characters
 Hierarchical naming support
► Dotted notation denotes hierarchy
● aix.system.boot.info
► 9 levels of hierarchy allowed
► Parent authorization is superset of children
 Authorization management commands:
► mkauth – Create authorizations
► chauth – Modify authorizations
► lsauth – List authorizations
► rmauth – Remove authorizations

 Use 'tracepriv' on unknown commands to get a list of their

requirements on privileges

22
Role Based Access Control (RBAC)
Privileged command Start
execution decisions:

Is Command Yes Is user Yes

in the
Authorized?
Database?

No
No

No Does Process
Raise Privilege to Bypass
Execution Fails Have File System
Access Rights Checks
Access Rights?

Color Key Yes

Historic
Behavior

New Decisions
Execution Allowed

23
 Role Based Access Control (RBAC)
Separation of duties through roles:

Main pre-defined AIX Roles:

ISSO Information Systems Security Officer
► Establishes and maintains security policy
SA System Administrator
► Creates user accounts, groups, etc.
► Installs software packages
SO System Operator
► Archives file system
► Manages line printer
► Shuts down system
Additional pre-defined AIX Roles:
AccountAdmin, BackupRestore, DomainAdmin, FSAdmin,
SecPolicy, SysBoot, SysConfig.

24
 Role Based Access Control (RBAC)
Role session transition:

 Each invocation of swrole creates a new role session

► Roles not inherited from previous session
 User may exit role session to return to previous role session

25
 RBAC example of some regular user:

# lsuser -f foo
foo:
id=203
pgrp=staff
groups=staff
home=/home/foo
shell=/usr/bin/ksh
login=true $ rolelist -e
su=true
rolelist: 1420-062 There is no active role set.
rlogin=true
$ bootinfo -r
[...] ksh: bootinfo: 0403-006 Execute permission denied.
roles=SysBoot $ swrole SysBoot
foo's Password:
$ rolelist -e
SysBoot System Boot Administration
$ bootinfo -r
524288
$ ^D
$ rolelist -e
rolelist: 1420-062 There is no active role set.

26
 AIX V6.1 Encrypting Filesystem
How it can help? What is it?
The capability to automatically
Go Green & Save
Login Authentication Module
encrypt data in a JFS2 filesystem
User and Group
CLiC
Crypto Lib
Key Stores Key Store
Mgt Cmds
BOS Cmds
Backup/Restore
Data can be protected from
Manage Growth,
Cp, mv, crfs, etc
access by privileged users
Data in clear in memory.
Complexity & Risk
Crypto Kernext
VMM Backup in encrypted or clear
Enables improved security by reducing Kernel ucred open
key store
J2
formats
unauthorized access to data, even by privileged Filesystem
users
Always encrypted on disk
Automated key management -
Secure backups reduces the exposure of data key store open on login,
compromised when backup media is taken
outside of secure facilities
integrated into AIX security
authentication
Automatic management of protection keys can
reduce the administrative effort of using Each file encrypted with a
encrypted data
unique key
No keys stored in clear in kernel
memory
Realize Innovation

A variety of AES, and RSA

Provides the capability for additional security
for applications that may have security design
cryptography keys supported
exposures

27
 Encrypted File System (EFS)
 Embedded in JFS2, not stacked, for performance and reliability
► all JFS2 operations can be performed with an EFS
● mounting and unmounting, increasing and decreasing size,
defragmenting, removing, ...
● No NFS or GPFS support
► Transparent to users and sysadmins
 Each file is encrypted with a separate key (stored in its meta data)
 Encryption/Decryption happens in memory, not on storage
 User keystore gets opened and loaded by login password or separate pw
► login pw is distinct from keystore pw
► Keystore holds user's private and public key (asymmetric encryption, RSA)
► Access to data via symmetric encryption (AES)
► Access to keys for symmetric encryption via asymmetric (RSA) encryption
► RSA wraps the symmetric key used for encrypting files

28
 Encrypted File System (EFS)
 Prereqs
► CryptoLite in C (CLiC) library and kernel extension must be installed and loaded
► Enhanced RBAC must be enabled (default in AIX6)
► EFS must be explicity enabled (can be done at any time using 'efsenable')
► ‚‘efsenable‘ creates the EFS keystore

 New and existing FSs can be encrypted

► smitty crfs -> "Enable EFS? [yes]"
► 'crfs' or 'chfs' along with "-a efs=yes"
► not to be applied on "/", /usr, /var and /opt since keystore can't be opened during boot
● but that's OK, since EFS' main focus is on protecting user/application data
► encrypted files can be identified by 'ls -U'
● # ls -U file*
-rw-r--r--- 1 root system 0 May 14 13:22 file1
-rw-r--r--e 1 root system 0 May 14 13:22 file2

 User key management is provided with 'efskeymgr' command

 Performance penalty is said to be low
► best practice: use it selectively where needed, not everywhere
e.g. on sensitive filesystems only, selected DB columns, etc.

29
 Encrypted File System (EFS)

Clear
File
Logs in Edit abc access

password generates access key,

access key opens keystore

PKCS#12

File System
Layer
Keystore
Memory

Key Cache
keystore contains user's private
and public key (RSA 1, 2, 4K)
(current and old ones)
each file's datablocks are encrypted Encrypted
symmetrically using individual keys, stored in
their EAs, AES (128, 192, 256 CBC+ECB)
File
those symm. keys are "enveloped" with
authorized users' public keys

30
 Encrypted File System (EFS)

 Two keystore protection modes

► Root Admin Mode
● Pro: Root can reset user and group key store access passwords
● Con: Root might be able to gain access to a user’s key store and
encrypted files
► Root Guard Mode
● Pro: Root cannot reset user and group key store access passwords
● Con: Root cannot gain access to a user’s key store and encrypted
files, even when neccessary!
 EFS backup Best Practices
► Backup raw encrypted form
► Backup the file owner’s keystore
► The file owner’s keystore password must also be "saved" or files must
be reencrypted in a timely manner when keystore pw changes

31
 Trusted AIX (MLS)

 Integrated Multi Level Security Model

► DAC - traditional Discretionary Access Control (user defined)
► MAC - Bell-LaPadula's Mandatory Access Control (system defined)
► MIC - Biba's Mandatory Integrity Control (system defined)
► Role definition and separation of duty
● e.g. user creation by security officer: SO and User login enablement by
Information System Security Officer: ISSO
► Labels on objects, subjects, labeled printing, labeled networking
► Trusted operating system: integrity checker, trusted path

=> a system's policy defines and enforces rights and permissions, not
some user (at their discretion)
 Installtime-only option
 Meet or exceed government standards for maximum security

32
 Trusted AIX (MLS)

 MAC and MIC are additional

MIC Object
layers to DAC
DAC
 All checks have to be MAC
passed to get access
DAC MAC

 Default settings
provide the MIC
usual "look and feel"

Subject

33
 Long Password / Passphrase Support
 Support for > 8 character user passwords
 Loadable Password Algorithms (LPAs) introduced 5.3 and 5.2
 No additional filesets needed
 Default is still 'crypt'
 Configured in /etc/security/login.cfg and /etc/security/pwdalg.cfg
► can be activated and deactivated (fallback to crypt) any time
► replaces passwords once they're set or changed
► existing passwords remain unchanged
► Store passwords with algorithms MD5, SHA{1,256,512} and blowfish
► Up to 255 characters
► Passphrase support <<My vacation to Hawaii‚>>
Ex
am
usw: ple
shells = /bin/sh,/bin/bsh,[...]
maxlogins = 32767
logintimeout = 60
maxroles = 8
auth_type = STD_AUTH
pwd_algorithm = ssha512
34
 Miscellaneous new features (many already available in 53...)

 LDAP Enhancements
► e.g. 'lsldap' and Microsoft Active Directory support for AIX clients
 IPSec enhanced w/ AES
 Secure ftp
 TCP Wrappers
► open source programs that allow access control on TCP connections
 ipfilter
► Open Source IP filter tool and NAT (network address translation)
► multi-platform; one set of rule for heterogeneous environment
 SED - Stack Execution Disable
► general buffer overflow exploit prevention
► Buffer overflows still most common security exploits
 Cryptographic Accelerator PCI-X adapter with support for CCA and PKCS#11

35
 Resources
 Redbook SG24-7430 "AIX 6 Advanced Security Features:
Introduction and Configuration"
► http://www.redbooks.ibm.com/abstracts/sg247430.html?Open
● Excellent reference, good overview and intros to various topics, e.g.
cryptography, I/T security in general, etc.
● May not be 100% technically accrate due to late changes in beta code

 The AIX 6.1 Security Guide

► http://publib.boulder.ibm.com/infocenter/pseries/v6r1/topic/com.ibm.
aix.security/doc/security/security.pdf
● Deep dive reference as part of the system documentation in InfoCenter

36
 Role Based Access Control (RBAC)
Naming convention for authorizations: hierarchical

device
fs create "Create Boot Image"

network halt "Halt the System"

boot info "Display Boot Information"

proc reboot "Reboot the System"
aix config
ras shutdown "Shutdown the System"

install
security
stat
system
wpar
aix.system.boot.info
/usr/sbin/bootinfo:
E
xa
accessauths = aix.system.boot.info mp
innateprivs = PV_DAC_R,PV_DAC_W,PV_DEV_CONFIG,PV_KER_RAS le

37
 Trusted AIX (MLS)

 MAC: Bell-LaPadula Confidentiality Model

► Access control security attributes:
● Hierarchical security levels
● Non Hierarchical categories
► Emphasis on leakage of information and the access control
► Focus on data

write same

subject object
(HIGH SL) read same (HIGH SL)

write read
write read up up
down down

read same
subject
object
(LOW SL)
(LOW SL) write same

38
 Trusted AIX (MLS)

 MIC: Biba Integrity Model

► Access control security attributes:
● Hierarchical integrity levels
● Non hierarchical integrity categories
► Emphasis on modification of information and thus ensuing integrity issues
► Focus on execution

write same

subject object
(HIGH IL) read same (HIGH IL)

write read
write read up up
down down

read same
subject
object
(LOW IL)
(LOW IL) write same

39