This presentation was made by Alex Peshkoff, Firebird Core developer in 2008 at Bergamo Firebird Conference. Alex is responsible for implementing security plans in Firebird, and here he gives insights on past issues with security in InterBase, caused by Borland "workarounds", and introduces brand new approach for security in Firebird 2.5 and 3.0
- 1.Security in Firebird:2.1, 2.5, 3.0
2. First years of InterBase
- In order to understand security problems of Firebird, we should
consider historical issues
- At that time there was another approach to database and server
security
3. First years of InterBase
- 1984 hardware and software was not like today
- No Internet like we see it today
- Hardware (PDP11, VAX11) requirements to run RDBMS
- Multiuser mode is 'many processes', not 'many threads'
relatively safe even in case of buffer overflow
4. First years of InterBase
- No strong requirements to RDBMS security
- No abilities to support strong requirements even if they
presented
- Lot of small buffers without overflow control
- External tables and UDFs one can store any data as external
table and call as UDF
RDBMS is anyway safe! 5. Approach to security in Borland
-
- Need to have own users list database isc4.gdb
-
- Access to it from server itself for authentication purposes
(use of login 'politically' and password 'correct' for it)
-
- Local access protocol using Windows events (PostEvent(),
etc.)
6.
-
- Use of multi-thread access model instead of mutli-process
-
- No buffers' size review (!)
-
- No integration between own users list and host OS accounts
-
- Local protocol is still using Windows Events
-
- Runs as LocalSystem account
Borland security solutions for InterBase 7. Firebird security
development
- Fixed serious vulnerability was eliminated
-
- politically correct left the building
- Assessment of the most dangerous places in firebird code
base
8. Firebird security development
-
- 'root' (LocalSystem) server execution (in Windows prevents use
of local access protocol)
-
- Arbitrary code execution using standard SQL language tools
(External Table + UDF)
-
- Access to any database as a 'raw' file
9. Firebird security development
-
- More buffers overflows fixed
-
- Ability to read passwords' hashes from security database using
any valid login
-
- Started code review in order to completely avoid buffer
overflows in strings (file names, etc.)
-
- User can change own password (only superuser could change any
password before)
10. Firebird 2.1- what's new
-
- Finished buffers overflow hunting no new bugreports during last
year.
-
- Use Windows trusted authentication to login to Firebird
server
11. Firebird 2.1: windows trusted authentication
- Authentication using own security database
Client Server Attach Accept (or reject) 12. Firebird 2.1:
windows trusted authentication
- Using windows trusted authentication
Client Server ......
- May require passing data between client and server many
times.
- Use native authentication API
Attach trusted Request to adjust security contex Adjusted
security context Accept (or reject) 13. Traditional
authentication(client) fbclient library isc_dpb_user_name
isc_dpb_password ......... Environment variables isc_dpb_user_name
isc_dpb_password ......... Login/password may be picked up from
environment by client library ISC_USER=.. 14. Traditional
authentication(server) Network listener Database engine
Validationin security database isc_dpb_user_name isc_dpb_password
......... isc_dpb_user_name isc_dpb_password Validation is
performed by DB engine 15. Trusted authentication (client)
isc_dpb_trusted ......... ......... ......... Environment variables
fbclient library Client library automatically adds trusted auth
request to DPB 16. Trusted Authentication (client) .........
......... isc_dpb_user_name isc_dpb_password ......... Environment
variables fbclient library Login is picked up from environmnet
(backward compatibility) ISC_USER=.. 17. Trusted Authentication
(client) isc_dpb_trusted isc_dpb_trusted ......... .........
Environment variables fbclient library Adding isc_dpb_trusted by
application to force trusted auth. ISC_USER=.. 18. Trusted
Authentication (server) isc_dpb_trusted Network listener ..........
isc_dpb_trusted ......... DB engine Host OS validation (callback)
Network listener does all work, on success puts internal tag into
DPB. 19. Trusted Authentication (server) isc_dpb_trusted Network
listener .......... isc_dpb_trusted ......... isc_dpb_trusted Host
OS validation (callback) DB engine Safe - network listener removes
extra isc_dpb_trusted tags from DPB 20. Firebird 2.5 - what's
new
-
- Attack on server using large packets with garbage
-
- User management in SQL (CREATE / ALTER / DROP USER)
-
- Configure mapping of domain administrators to RDB$ADMIN role
using SQL
-
- New GRANTED BY clause in GRANT and REVOKE operators
21. Firebird 2.5 - what's new
- CREATE USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME
'middle' LASTNAME 'last'
- ALTER USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME
'middle' LASTNAME 'last'
22. Firebird 2.5 - what's new
- In firebird 2.5 this commands always work with common security
database security2.fdb
- Alter User is available for all users, the rest only to
SYSDBA
23. Firebird 2.5 - what's new
- GRANT RDB$ADMIN TO GUEST1
-
- When attaching to current database with role RDB$ADMIN user
GUEST1 will have all rights of database administrator (SYSDBA)
- REVOKE RDB$ADMIN FROM GUEST1
24. Firebird 2.5 - what's new
- Configure mapping of domain administrators to RDB$ADMIN role
using SQL
- ALTER ROLE RDB$ADMIN SET / DROP AUTO ADMIN MAPPING
-
- This is restricted form of a command, planned to control
mapping of host OS objects to database objects in firebird 3
25. Firebird 2.5 - what's new
- New GRANTED BY clause in GRANT and REVOKE operators
-
- Makes it possible for SYSDBA to revoke rights, granted by other
users
26. Firebird 2.5 - what's new
- GRANT role1 TO user1 WITH ADMIN OPTION;
- REVOKE role1 FROM PUBLIC GRANTED BY user1;
27. Firebird 3(plan)
- Authentication architecture review when using OSRI in
firebird
- Choose (at configuration level) any database as security
database, including target database itself
- Mapping OS objects to database objects (groups, users,
etc.)
28. OSRI (Open System Relational Interface) Engine13 Yvalve
Network listener User program (isql, php, etc.) Engine8_12 Network
redirector Providers Clients In FB3 we plan to have OSRI alive
again. How does it affect auth? 29. IB, FB1, FB2 user
authentication is in engine Yvalve Network listener Engine rear
entrance is used to avoid recursion politically correct- InterBase
4, 5, 6 TLS Firebird 1, 2 Authentication Engine needs a way to call
itself for authentication purporses without authentication avoiding
infinite recursion 30. Firebird3 - user authentication in network
listener Yvalve Network listener Providers Engine8_12 Engine13
Network redirector Authentication Plugins trusted zone
Authenticator and plugins can easily use all our API in-process
access to it. No need in any rare entrance. 31. Firebird
3(plan)
- Choose (at configuration level) any database as security
database
- FileName = $(root)/db/data1.fdb
- Security = $(root)/db/secure.fdb
- FileName = /raid/data.fdb
- Security = $(root)/security2.fdb
32. Firebird 3(plan)
- Choose any database as security database another configuration
file format, same effect
- FileName = $(root)/db/data1.fdb
- Security = $(root)/db/secure.fdb
- FileName = /raid/data.fdb
- Security = $(root)/security2.fdb
33. Firebird 3(plan)
-
- Use any authentication methods
-
- Current security database
-
- Trusted authentication from 2.1
-
- Trusted authentication based on asymmetric keys match: public
stored on server (in database), private stored by client
-
- Passwords verified in LDAP, PAM, etc.
-
- Unlimited length of password
-
- Use CHAP to validate passwords
34. Firebird 3(plan)
- Mapping OS objects to database objects
- Configured on per-database basis using SQL:
-
- ALTER ROLE name ADD OS_NAME 'os_name'
-
- ALTER USER name ADD OS_NAME 'os_name'
-
- ALTER ROLE name DROP OS_NAME 'os_name'
-
- ALTER USER name DROP OS_NAME 'os_name'
35. Firebird 3(plan)
- Mapping OS objects to database objects
- OS object may be mapped not more then to single user and single
role
-
- ALTER USER user1 ADD OS_NAME 'guest'
-
- ALTER USER user2 ADD OS_NAME 'guest'
-
-
- Running second command throws an error
36. Firebird 3(plan)
- Mapping OS objects to database objects
- Security plugin builds a list of OS objects, each of them is
assiggned a kind of priority lower digit means higher
priority.
- Priority 0 means 'use this object as current_user
unconditionally'
- Providers use information from this list (passed in DPB) to
obtain CURRENT_USER and CURRENT_ROLE values.
37. Firebird 3(plan)
- Mapping OS objects to database objects
- Sample 1 authentication in security database
- Security database authentication (when successful) puts single
object in a list:
38.
Firebird 3(plan) Mapping result: current_user = USERNAME
current_role = NONE
- Example 1 - authentication is security database
39.
- ALTER USER SYSDBA ADD OS_NAME 'username'
Firebird 3(plan) Mapping result: current_user = SYSDBA
current_role = NONE
- Example 1 - authentication is security database
In this was we have an easy way to grant people god rights in
particular database. 40. Firebird 3(plan)
- Mapping OS objects to database objects
- Example 2 windows trusted authentication
- Typically this plugin will put in the objects' list something
like:
41.
Firebird 3(plan) Mapping result: current_user = DomUser
current_role = NONE
- Example 2 windows trusted authentication
42.
- ALTER ROLE RDB$ADMIN ADD OS_NAME 'Domain Admins'
Firebird 3(plan) Mapping result: current_user = DomUser
current_role = RDB$ADMIN
- Example 2 windows trusted authentication
43.
- ALTER ROLE RDB$ADMIN ADD OS_NAME 'Domain Admins'
- ALTER ROLE USERS ADD OS_NAME 'Domain Users'
Firebird 3(plan) Mapping result: ERROR what role to choose?
- Example 2 windows trusted authentication
44.
- ALTER ROLE RDB$ADMIN ADD OS_NAME 'Domain Admins'
- ALTER ROLE USERS ADD OS_NAME 'Domain Users'
- ALTER ROLE USERS ADD OS_NAME 'DomUser'
- Use of higher-priority mapping (1) makes it possible to resolve
conflict i.e. users mapping is always prefered over group.
- Users may be mapped to roles and groups to users.
Firebird 3(plan) Mapping result: current_user = DomUser
current_role = USERS
- Example 2 windows trusted authentication
45.
- ALTER ROLE RDB$ADMIN ADD OS_NAME 'Domain Admins'
- ALTER ROLE USERS ADD OS_NAME 'Domain Users'
- ALTER ROLE USERS ADD OS_NAME 'DomUser'
- ALTER USER GUEST ADD OS_NAME 'DomUser'
- This example shows how you should NOT setup mapping in your
databases!
Firebird 3(plan) Mapping result: current_user = GUEST
current_role = USERS
- Example 2 windows trusted authentication
46.
- ALTER ROLE RDB$ADMIN ADD OS_NAME 'Domain Admins'
- ALTER ROLE CHIEF ADD OS_NAME 'Chief'
- ALTER ROLE FINANCE ADD OS_NAME 'Finance'
- This is real-life example.
Firebird 3(plan) Mapping result: current_user = DomUser
current_role = FINANCE
- Example 2 windows trusted authentication
47. Thanks for your attention! www.firebirdsql.org