User Group Informix France
New Security Features in IDSNew Security Features in IDS
Yoram Benchetrit
Mardi Mardi 3030 novembre novembre 20102010
User Group Informix France
AgendaAgenda
�Mapped Users
�Trusted Context
�Selective Row Level Auditing
User Group Informix France
Why do we need this feature Why do we need this feature ??
� Local Account Look-up Availability
– Although IDS has supported PAM since 9.40.xC2, users have had to enable look up of the user account on the host Operating System
� Redundant Password Comparaison
– Even though PAM or Windows AD has authenticated the users, IDS obtains the users' hashed password and does a redundant password comparison
• The users password (encrypted) must be accessible to IDS
• LDAP users have had to enable the password property for the LDAP “proxy” user
• Where customers use Windows AD, they have had to turn on Unix password property for the users.
� Customers unhappy to do either of the two
User Group Informix France
User StoryUser Story
� Microsoft Active Directory (LDAP) – As a DBSA, I need to allow users identified in MS Active
Directory (AD) to connect to IDS without being forced to create a Unix login account for the users
� Users with PCs – We use PAM to authenticate our users. Why do we need to
create accounts in the local operating system?
� Administrator Roles for External Users – As a DBSA, I should be able to grant an externally
authenticated users server administrator roles
User Group Informix France
Feature Quick ReferenceFeature Quick Reference � Authenticate external users without an OS account
– Database users no longer need
• An account Look-up in the local OS
• Enable password properties for external authenticators
� The DBSA “maps” an external user to: • An existing OS user or
• A database defined UIG/GID pair
� Uses an extension to the GRANT/REVOKE SQL statement
� Requires PAM or SSO authentication
� Traditional password based authentication is still available
� Windows support is pending
User Group Informix France
Feature Details Feature Details –– 11--22--33!!!!!!
1.Enable USERMAPPING in ONCONFIG
2.Setup PAM or SSO via SQLHosts
3.GRANT ACCESS TO <users> PROPERTIES
That is it...!!
User Group Informix France
Feature Details Feature Details –– ONCONFIGONCONFIG
� New ONCONFIG parameter
USERMAPPING { OFF | BASIC | ADMIN }
• OFF
This feature is turned off – this is the default
• BASIC
IDS non-privileged users – not DBSA, DBSSO or AAO
• ADMIN
Enabled privileged users
User Group Informix France
Feature Details Feature Details –– SyntaxSyntax
� Extension to GRANT statement – GRANT ACCESS TO {username} PROPERTIES
[ USER OS_username | UID uid ] GROUP (OS_groupname | gid), HOMEDIR ‘homedir’, AUTHORIZATION (userauth);
– 'userauth' is an OR pattern of DBSA, DBSSO, AAO, BARGROUP
User Group Informix France
Feature Details Feature Details –– Syntax Syntax ((contcont))
� Examples
– GRANT ACCESS TO user1 PROPERTIES USER ravik;
– GRANT ACCESS TO user2 PROPERTIES UID 100, GROUP (200);
– GRANT ACCESS TO user3 PROPERTIES USER ravik, HOME '/home/user4’;
– GRANT ACCESS TO user4 PROPERTIES USER ravik AUTHORIZATION (dbsa);
– GRANT ACCESS TO PUBLIC PROPERTIES USER ravik;
User Group Informix France
Feature Details Feature Details –– Syntax Syntax ((contcont))
� Extension to REVOKE statement
– REVOKE ACCESS FROM { PUBLIC | <username> }
� Example – REVOKE ACCESS FROM user1;
� To alter a user mapping revoke and re-grant access – Error: -26107 User name (%s) has already been granted
User Group Informix France
Feature Details Feature Details -- CapabilitiesCapabilities � OS processes
– SYSTEM commands in a procedure will run as the surrogate user
� OS Files – Sqexplain Files will be created as the surrogate user
– Debug Files will be created as the surrogate user
– Unload and Output Files will be created as the surrogate user
� Home Directory (optional) – If the home directory is not specified, IDS will create a directory for user file in
$INFORMIXDIR/users/uid.<id_number>
– If user is mapped to non-existent uid/gid pair, file will be created using that UID/GID only if the directory is publicly writable
� Role Separation – IXUSERS group in $INFORMIXDIR/dbssodir/seccfg
• A Mapped User cannot be part of IXUSERS group if surrogate user is invalid: Error -25571 “cannot create a user thread”.
User Group Informix France
Example SetupExample Setup
� ONCONFIG ####################################################################
# USERMAPPING - Control access to IDS for users without operating # system accounts. #################################################################### # OFF - users without operating system accounts cannot use IDS # BASIC - users without operating system accounts can use IDS but # not as privileged users # ADMIN - users without operating system accounts can use IDS as # privileged users #################################################################### USERMAPPING BASIC
� PAM Configuration /etc/pam.d/idspam
# LDAP authentication
auth required pam_ldap.so
account required pam_ldap.so
� SQLHosts idsserver onsoctcp linx idsservice s=4, pam_serv=(idspam), pamauth=(challenge)
User Group Informix France
Example Example –– LDAP Mapped UserLDAP Mapped User
� LDAP Configuration /etc/ldap.conf # LDAP server host ldapserver ... # The distinguished name of the search base base dc=yobldap-domain,dc=com
� User Mapping Definition
[informix@linx]$ dbaccess stores_demo <<EOF GRANT ACCESS TO ldap_user PROPERTIES USER yob; EOF
� IDS Connection [informix@linx ]$ dbaccess - - > connect to ‘stores_demo@idsserver’ user 'ldap_user' > Password: <- type ldap password Connected.
User Group Informix France
Open Admin Tool Support Open Admin Tool Support ((OATOAT))
� GUI Interface support is provided through Open Admin Tool
– Server Administration
• User Privileges
– Add, Edit, Delete, Show SQL
User Group Informix France
System TablesSystem Tables
� New system tables in 'sysuser' database
– SYSUSERMAP
– SYSSURROGATES
– SYSSURROGATEGROUPS
� DBSA should use the GRANT ACCESS TO / REVOKE ACCESS FROM statements to manage the system tables as there are cross-references !
User Group Informix France
System Tables System Tables ((contcont))
� SYSUSERMAP
Column name Type Nulls
username nchar(32) yes
surrogate_id integer yes
User Group Informix France
System Tables System Tables ((contcont))
� SYSSURROGATES
Column name Type Nulls
surrogate_id serial no
os_username nchar(32) yes
uid integer yes
gid integer yes
groupname nchar(32) yes
homedir nvarchar(255) yes
userauth char(10) yes
User Group Informix France
System Tables System Tables ((contcont))
� 'userauth' Entry in SYSSURROGATES
– An OR pattern of
• Position 1: s = DBSA
• Position 2: o = DBSSO
• Position 3: a = AAO
• Position 4: b = BARGROUP
• Other positions reserved for future use
• Attributes in lower case only
� Example s - - b - - - - - - The user is a DBSA and belongs to BARGROUP
- o - - - - - - - - The user is an AAO
� If the 'userauth' entry is not specified, the user is non-privileged
User Group Informix France
System Tables System Tables ((contcont))
� SYSSURROGATEGROUPS
Column name Type Nulls
surrogate_id integer yes
gid integer yes
groupname nchar(32) yes
groupseq smallint yes
User Group Informix France
Why do we need this feature Why do we need this feature ??
� In a 3-tiers architecture, the middle-tier's user must have all the privileges needed to execute all the requests from all users
� There is a security issue of accessing resources on behalf of users if the middle-tier's user is compromised
� There is a lost of information when auditing needs to distinguish end-users from middle-tier's user
� Establishing new connection may suffer performance drop which is also the case when using connection pool
User Group Informix France
Feature Quick ReferenceFeature Quick Reference
� This feature allow to reuse a connection for a different user without the need to establish a new connection
� The purpose is to avoid connection overhead when there is a need to connect on behalf of new users, which is the case in application server
� This also provide higher security level and better auditing granularity, as each user connect and switch on a trusted connection with their own credentials and privilege
� New SQL statement are provided and/or enhanced to create trusted context, establish trusted connection and provide connection switch capabilities
� All users properties are reported for the switched connection user when established
User Group Informix France
Trusted Context ObjectTrusted Context Object
� A Trusted Context is a database object created by the database security administrator (DBSECADM) that defines a set of properties for a connection that when met, allow that connection to be a “trusted connection” with special properties.
– The connection must be established by a specific user.
– The connection must come from a trusted client machine.
– The port over which the connection is made must have the required encryption.
� If these criteria are met, the connection will allow changes in userid and privileges as defined in the trusted context.
User Group Informix France
Trusted Context SetupTrusted Context Setup
� Step1 : Create Trusted Context Object – Created at database level
– Must be created by DBSECADM
– Can use OS users or Mapped Users
– Provision to Switch User
� Step 2: Establish Trusted Connections – Use SQL statement to establish trusted connection
– Must satisfy criteria defined in Trusted Context
� Step 3: Switch Connections – Use SQL Statement to switch user over a trusted connection
– New operations performed for the switched user
User Group Informix France
Trusted Context SyntaxTrusted Context Syntax
� Syntax (simplified) – CREATE TRUSTED CONTEXT <ctx>
BASED UPON CONNECTION USING SYSTEM AUTHID <user> ATTRIBUTES (ADDRESS <host>, WITH ENCRYPTION <value>) DEFAULT ROLE <role> WITH USE FOR <user list> [WITH | WITHOUT] AUTHENTIFICATION ENABLE | DISABLE
� Users with DBSECADM role can perform following operations – CREATE TRUSTED CONTEXT
– ALTER TRUSTED CONTEXT
– DROP TRUSTED CONTEXT
User Group Informix France
Trusted Context CreationTrusted Context Creation
� New SQL statement to create a trusted context CREATE TRUSTED CONTEXT mytcx BASED UPON CONNECTION USING SYSTEM AUTHID yob DEFAULT ROLE employee ATTRIBUTES (ADDRESS 'linx.swglab.fr.ibm.com') WITH USE FOR PUBLIC WITHOUT AUTHENTICATION ENABLE
– Creates an Trusted Context object named 'mytcx'
– The connection can be established by user 'yob'
– Will allow connections from 'linx.swglab.fr.ibm.com'
– Can switch to any users (PUBLIC) once Trusted Connection established
User Group Informix France
Trusted Connection EstablishmentTrusted Connection Establishment
� New keyword in the “connect” SQL statement to establish a trusted connection – EXEC SQL CONNECT TO “stores_demo@ids1170” TRUSTED
– Detail in online.log
• 18:21:07 TESTMODE: trust context address 9.101.46.52 matched
• 18:23:12 listener-thread: err = -28021: oserr = 0: errstr = : Trusted
Connection request rejected.
� Front-End API Support – ESQL/C
– ODBC
– JDBC
User Group Informix France
Trusted Connection SwitchTrusted Connection Switch � There is a SQL statement to switch over a trusted
connection – EXEC SQL SET SESSION AUTHORIZATION to <user> [ USING <passwd> ]
– EXEC SQL SET SESSION AUTHORIZATION to “joe”
� Switch to any user defined in the Trusted Context Object scope
� Audit records will show the switched user as the originator of the operations
� Need to commit or rollback before switching to a new user when using transactions
User Group Informix France
Open Admin Tool Support Open Admin Tool Support ((OATOAT))
� GUI Interface support is provided through Open Admin Tool
– Server Administration
• Trusted context
– Create, Modify, Delete, Enable, Show SQL
User Group Informix France
Trusted Context Wizard Trusted Context Wizard ((OATOAT))
� Trusted Context > View
User Group Informix France
Trusted Context Wizard Trusted Context Wizard ((OATOAT))
� Trusted Context > Create
– STEP 1
User Group Informix France
Trusted Context Wizard Trusted Context Wizard ((OATOAT))
� Trusted Context > Create
– STEP 2
User Group Informix France
Trusted Context Wizard Trusted Context Wizard ((OATOAT))
� Trusted Context > Create
– STEP 3
User Group Informix France
Trusted Context Wizard Trusted Context Wizard ((OATOAT))
� Trusted Context > Create
– STEP 4
User Group Informix France
System TablesSystem Tables
� New Tables In Database ‘sysuser’
– table systrustedcontext (
contextid serial,
contextname varchar(128),
database char(128),
authid char(32),
defaultrole char(32),
enabled char(1) not null,
encryption char(1));
– table systcxattributes (
contextid integer not null,
address char(64),
encryption char(1));
– table systcxusers (
contextid integer not null,
username char(32),
usertype char(1),
userrole char(32),
authreq char(1));
User Group Informix France
System Table QuerySystem Table Query
� Trusted Context Definition in 'sysuser' database – [root@linx trustedContext]# cat sel_trusted_ctx.sql
SELECT a.contextid, contextname, database, authid, defaultrole, enabled, a.encryption, address, username, usertype, userrole, authreq FROM systrustedcontext a, systcxattributes b, systcxusers c WHERE a.contextid = b.contextid AND b.contextid = c.contextid
– [root@linx trustedContext]# dbaccess sysuser sel_trusted_ctx.sql Database selected. contextid 1 contextname mytcx1 database stores_demo authid informix defaultrole enabled Y encryption N address 9.101.46.52 username PUBLIC usertype G userrole authreq N 1 row(s) retrieved. Database closed.
User Group Informix France
Why do we need this feature Why do we need this feature ??
� Row level auditing produce huge amount of useless data because audited tables are not all important to system security.
� Some Customer have reported 30% database performance drop when turning on row level auditing for insert/update/delete operation
� The information in the current row-level audit records contains table_id and row_id. These can change over time which can make looking back at audit records meaningless.
User Group Informix France
Feature Quick ReferenceFeature Quick Reference
� This feature allow to specify which tables are audited at row level
� The purpose is to avoid performance drop during auditing whenever all tables and rows are audited
� This feature is turned on by setting ADTROWS in adtcfg file, or dynamically with onaudit -R <value>
– Backward compatibility
� New SQL command are provided to define which tables are audited at row level
� An audit trail file is generated and filtered with onshowaudit utility
User Group Informix France
Audit EventAudit Event
� IDS 11.70 has 159 Audit Event
� Audit Event Naming Convention
– 'aaoo'
• with 'aa' : 2 letter code for action
• 'oo' : 2 letter code for the object
� There is a mapping for audit event id to event mnemonic
� The feature is implemented for 4 audit event mnemonic
– INRW : Insert Row
– UPRW : Update Row
– DLRW : Delete Row
– RDRW : Select Row
User Group Informix France
SRLA SetupSRLA Setup
� There is a new parameter called ADTROWS in adtcfg file
– 0: old behavior i.e. no changes in row level auditing (default)
– 1: SRLA is enabled and only "audit" enabled tables will generate row-level audit records.
– 2: SRLA + include integer-primary key in the audit records
� The feature can be turned on dynamically
– onaudit -R 1
User Group Informix France
Audit SQL SyntaxAudit SQL Syntax
� There is new SQL statements to specify which table to audit – CREATE TABLE {existing syntax} | with AUDIT
– ALTER TABLE {existing syntax} [ add | drop ] AUDIT
� Anyone with RESOURCE or DBA permission can either – Create the table «WITH AUDIT »
– Alter the table to « ADD AUDIT »
� Only a DBSSO can « DROP AUDIT » on a table.
User Group Informix France
ExampleExample
� Setup Auditing with SRLA feature in adtcfg file
� Setup Audit Event with onaudit utility
� Add a table audit property to enable auditing on a specific table
� Execute a select statement against the specific table
� Monitor auditing file to verify only specific table is beeing audited
User Group Informix France
Example Example ((contcont))
� $INFORMIXDIR/aaodir/adtcfg configuration file
ADTMODE 1 # auditing mode ADTPATH /opt/informix/aaodir # audit trails file ADTSIZE 50000 # Max size of any single audit trail file ADTERR 0 # Error handling modes. ADTROWS 2 # 0 - For legacy auditing # 1 - log audit tables # 2 - 1+log primary key
� Enable auditing and mask definition
[informix@linx]$ onaudit -R 2 [informix@linx]$ onaudit -p /opt/informix/aaodir [informix@linx]$ onaudit -l 1 [informix@linx]$ onaudit -a -u yob -e +INRW,UPRW,DLRW,RDRW
� Setup table property for auditing
[informix@linx]$ echo 'alter table customer add audit' | dbaccess stores_demo
User Group Informix France
Example Example ((contcont))
� Audit Event caught for table read
[yob@linx ~]$ echo 'select * from customer' | dbaccess stores_demo [informix@linx aaodir]$ cat ids.0 ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:257:101 ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:258:102 ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:259:103 ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:260:104 ... ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:525:127 ONLN|2010-03-18 10:58:43.000|linx|5359|ids|yob|0:RDRW:stores_demo:100:1048976:526:128
� Audit Record Format – Fixed Part
• tag, date, host, pid, informixserver, user
– Variable Part :
• errno, event, database, tabid, partnum, rowid, primary key
User Group Informix France
MerciMerci
Yoram Benchetrit
Mardi Mardi 3030 novembre novembre 20102010