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

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!

AIX Security Features What Do I really need?

Feature
AIX Security Expert
Secure By Defualt
File Permission Mgr
Role Bases Access
Control

Encrypted Filesystem
Trusted Execution
Workload Partitions
Trusted AIX

Who Should Use it

EVERYONE!!! Hardening scripts can be added as additional rules
and invoked by AIX SE.
Users who want minimal filesets installed and want strict control on
what is added to the os. Network connectivity is disabled.
If you want to minimize programs with setuid bits on.
Organizations with many admins who dont want to give them all root
access and abilities.
Customers who want extra protection by encrypting files.
Organizations required by legislation to encrypt sensitive data.
Customers who want integrity checking on AIX os files and other
customer specific files.
Those who want added system isolation for applications/
environments; prevent them from interfering with one another
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?
Go Green & Save

Manage Growth,
Complexity & Risk

Can reduce the cost and complexity of security

administration by allowing federated
management of security profiles across multiple
servers
Enables a more secure IT infrastructure by
reducing the effort of maintaining system
security
Check functionality can provide additional
security by validating that the security profile for
each system matches the actual security
settings

Realize Innovation

Allows for new ways to efficiently manage

security across multiple AIX systems

What is it?
A centralized security
management tool that can
control over 300 security settings
from a single console
Administrators can start from a
Low, Medium, High or
Sarbanes-Oxley security
template and customize settings
to met business requirements
Security settings can be
exported and imported as a
security profile to multiple
systems
On AIX V6.1, security profiles
can be stored in an LDAP
directory for ease of distribution
AIX Security Expert was first
included in AIX V5.3 TL5
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

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!

AIX Security Expert Hardening Groupings

Policy Grouping
Description
Password
/etc/inetd.conf
/etc/tcpip settings
Setuid Policy

/etc/inittab
Audit Policy

Aging, lengh, reset, expiration and valid characters

Disables programs such as tftp, telnet, UCP echo, rshd, and rexd
Disables many TCP apps in high security
Removes setuid bits with fpm
Disables programs like qdaemon, lpd, and piobe
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

Password Checking
Check settings at a later
time
9

Sets policy to improve record keeping for audits

Stringent dictionary checks for eliminating weak passwords
Verify that the initial settings are still valid

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

10

Can all applications' requisites be fulfilled by this install template?

Secure by Default (SbD)

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

12

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

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**

Signature
Database

Certificates
Database

Integrity Checker
Tool

System Integrity Status

Trojan Horse Detection

Executable/
Module

vs.

Calculate
Hash

Hash/
Signature
Database
Policy Engine

Eg: Disallow loads on non-match

Memory

15

AIX V6.1 Role Based Access Control (RBAC)

How it can help?
Go Green & Save

Manage Growth,
Complexity & Risk

Can reduce the cost and complexity of security

administration by allowing secure delegation of
administrative tasks to non-privileged users

What is it?
A new capability of AIX V6.1
that allows privileged
administration tasks to be
delegated to non-privileged
users
Access to system resources are
associated with roles that are
assigned to non-privileged users

Enables a more secure IT infrastructure by

reducing the need for so many privileged
administrators

Many roles are predefined

which can reduce the effort of
implementing RBAC

Assigning roles to programs can reduce the

need for security exposures such as the use of
setuid for programs

Roles can also be associated

with programs

Realize Innovation

Allows for new ways to delegate administration

duties between system administrators and nonadministrative 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

Root necessary, but security concerns

Install, backup/restore, user management, etc.

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

enhanced_RBAC system environment variable

LDAP and WPARs supported

The end of 'sudo' ?

18

(default)

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

19

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

20

RBAC Infrastructure
Infrastructure to create and track authorization, roles and
priviledges are stored in separate databases

21

Authentication DB

Role DB

Priviledged command DB

Privileged device DB

Privledged File DB

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
execution decisions:

Start

Is Command
in the
Database?

Yes

Is user
Authorized?

Yes

No
No
Execution Fails

Color Key

No

Does Process
Have File System
Access Rights?

Yes

Historic
Behavior
New Decisions

23

Execution Allowed

Raise Privilege to Bypass

Access Rights Checks

Role Based Access Control (RBAC)

Separation of duties through roles:
Main pre-defined AIX Roles:
ISSO

Information Systems Security Officer

SA

Establishes and maintains security policy

System Administrator

SO

Creates user accounts, groups, etc.

Installs software packages

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
su=true
rlogin=true
[...]
roles=SysBoot

26

$ rolelist -e
rolelist: 1420-062 There is no active role set.
$ bootinfo -r
ksh: bootinfo: 0403-006 Execute permission denied.
$ 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.

AIX V6.1 Encrypting Filesystem

How it can help?
Go Green & Save

Manage Growth,
Complexity & Risk

Enables improved security by reducing

unauthorized access to data, even by privileged
users
Secure backups reduces the exposure of data
compromised when backup media is taken
outside of secure facilities
Automatic management of protection keys can
reduce the administrative effort of using
encrypted data

Realize Innovation

Provides the capability for additional security

for applications that may have security design
exposures

27

What is it?
The capability to automatically
encrypt data in a JFS2 filesystem
Data can be protected from
access by privileged users
Backup in encrypted or clear
formats
Automated key management key store open on login,
integrated into AIX security
authentication
Each file encrypted with a
unique key
No keys stored in clear in kernel
memory
A variety of AES, and RSA
cryptography keys supported

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

28

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

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

29

best practice: use it selectively where needed, not everywhere

e.g. on sensitive filesystems only, selected DB columns, etc.

Encrypted File System (EFS)

Edit abc

Logs in

Clear
File
access

password generates access key,

access key opens keystore

PKCS#12

Keystore

keystore contains user's private

and public key (RSA 1, 2, 4K)

File System
Layer
Memory
Key Cache

(current and old ones)

each file's datablocks are encrypted
symmetrically using individual keys, stored in
their EAs, AES (128, 192, 256 CBC+ECB)
those symm. keys are "enveloped" with
authorized users' public keys

30

Encrypted
File

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 users 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 users key store and encrypted
files, even when neccessary!

EFS backup Best Practices

31

Backup raw encrypted form

Backup the file owners keystore

The file owners keystore password must also be "saved" or files must
be reencrypted in a timely manner when keystore pw changes

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
layers to DAC

All checks have to be

passed to get access

MIC

Object
DAC

MAC
DAC

MAC

Default settings
provide the
usual "look and feel"

MIC

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>>

usw:

Ex
am
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.a
ix.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"

info

"Display Boot Information"

reboot

"Reboot the System"

shutdown

"Shutdown the System"

proc
aix

ras
security
system

boot
config
install
stat

wpar

aix.system.boot.info

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

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
(HIGH SL)

write
down

read same

object
(HIGH SL)

write
up

read
down
read same
object
(LOW SL)

38

write same

subject
(LOW SL)

read
up

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
(HIGH IL)

write
down

read same

object
(HIGH IL)

write
up

read
down
read same
object
(LOW IL)

39

write same

subject
(LOW IL)

read
up