 | Level: Intermediate Lynette D. Adayilamuriyil (lynetta@us.ibm.com), IDS Security Software Development Engineer, IBM
Manoj Mohan (manojm@us.ibm.com), IDS Security Software Development Engineer, IBM
24 Jul 2008 Protect your most sensitive data by using the Label-Based
Access Control (LBAC) feature of IBM® Informix® Dynamic Server V11
(and later). In this article, understand what LBAC is, and see how you can
implement it to meet your most demanding security standards.
Introduction
Identity theft and data breaches are some of the fastest-growing crimes in
United States. Personal data, like social security and credit card
numbers, is stolen to commit frauds and for economic gains. Criminals get
this data from computer networks, e-mails, mail, trash, and many other
places. Despite companies' best efforts to keep intruders out of networks
and sensitive systems, more than 70 percent of data breaches are carried
out by employees. In order to safeguard against intruders, most of the
databases use authentication to verify that users are who they say they
are; authorities and privileges control access to a database and the
objects and data that reside within it. However, existing access control
mechanisms are insufficient or add too much overhead to get the desired
results. IDS 11 provides a sound solution to these situation in
Label-Based Access Control. LBAC makes it possible to grant and restrict
read and write access to individual rows and columns based on an
employee's job function, department, or other designated criteria.
 |
What is LBAC?
Label-Based Access Control is a mechanism that lets a database system
control access to a database object based on a security label contained in
that object and the security label granted to the user attempting to
access that object. It is a form of mandatory access control.
The IDS implementation of LBAC allows control over who can access data in
individual rows and columns of a table. The LBAC capability is
configurable and can be tailored to match the user's particular security
environment.
A database security administrator, a user to whom the new DBSECADM role
has been granted, performs all LBAC configurations. The database security
administrator configures the LBAC system by creating security policies. A
security policy describes the criteria that is used to decide who has
access to specific data. After creating a security policy, the security
administrator creates security labels that are part of that policy.
Once created, a security label can be associated with individual columns
and rows in a table to protect the data held there. The database security
administrator allows users access to protected data by granting them
security labels. When a user tries to access protected data, that user's
security label is compared to the security label protecting the data. If
the user's security label dominates the data's security label, access is
permitted; otherwise, it is denied.
The database security administrator can also grant exemptions to users. An
exemption allows users access to protected data that the user's security
labels might have otherwise prevented from accessing. Together, the
security labels and exemptions are called LBAC credentials.
Database security administrator (DBSECADM)
Database security administrator (DBSECADM) is a new built-in role
introduced to perform all security-related administration, including setup
of the LBAC security infrastructure. It is a server-level role and can be
granted only by the database server administrator (DBSA).
The LBAC security infrastructure setup performed by DBSECADM includes
setting up security label components, security policies, security labels,
granting security labels and exemptions to users, and protecting tables by
attaching policies.
The DBSECADM role can be granted to users by DBSA as follows:
GRANT DBSECADM TO 'lynette', 'manoj';
|
Security label component
Security label components are the building blocks for security policies
and labels. There are three types of security label components: array,
set, and tree.
|
Security policy
Security policy defines the composition of the security labels and
specifies the rules used to control access to sensitive data. A security
policy is made up of security label components. There can be a maximum of
16 unique security components in a security policy.
A security policy can be created by DBSECADM as follows:
Listing 3. Create security policy
CREATE SECURITY POLICY MegaCorp
COMPONENTS level, department, region
WITH IDSLBACRULES;
|
Security label
Security labels are database objects applied to rows and columns in order
to protect data, and granted to users to give them access to protected
data. A security label belongs to a security policy and contains a value
for each security component in that security policy. A value in the
context of a security component is a list of zero or more of the elements
allowed by that component. Values for array type components can contain
zero or one element, and values for set and tree type components can have
zero or more elements.
A security label can be created by DBSECADM as follows:
Listing 4. Create security label
CREATE SECURITY LABEL MegaCorp.director
COMPONENT level 'Secret',
COMPONENT department 'Product Development', 'Quality Assurance',
COMPONENT region 'USA';
|
Security labels are applied to data in order to protect the data. They are
granted to users to allow them access to protected data. A user can be
granted at most two security labels for a security policy — one
for read and the other for write. A user can also have the same label for
both read and write access. When a user tries to access protected data,
his security label is compared to the security label that is protecting
the data. If the user's security label dominates the data's security
label, access is granted.
A security label can be granted to users by DBSECADM as follows:
Listing 5. Create security label
GRANT SECURITY LABEL MegaCorp.director TO 'john' FOR READ ACCESS;
GRANT SECURITY LABEL MegaCorp.manager TO 'john' FOR WRITE ACCESS;
GRANT SECURITY LABEL MegaCorp.director TO 'susan' FOR ALL ACCESS;
|
Access rules
Access rules can be divided into two categories: read access rules and
write access rules. Read access rules are applied when a user attempts to
read labeled data. Write access rules are applied when a user attempts to
insert, update, or delete labeled data. IDS has a predefined set of read
and write access rules that are collectively called IDSLBACRULES. When a
user tries to access labeled data, their security label is compared to the
security label that is protecting the data, and one or more of these
predefined rules will be used to determine if one label dominates another.
Read access rules
The read access rules are applied when data is read
(SELECT, UPDATE, and
DELETE operations) and can be summarized as
follows:
-
IDSLBACREADARRAY: Each array component of the user security
label must be greater than or equal to the array component of the data
security label to allow access to data.
-
IDSLBACREADSET: Each set component of the user security label
must include the set component of the data security label to allow
access to data.
-
IDSLBACREADTREE : Each tree component of the user security
label must include at least one of the elements in the tree component
of the data security label (or the ancestor of one such element) to
allow access to data.
Write access rules
Write access rules are applied when data is written
(INSERT, UPDATE, and
DELETE operations) and can be summarized as
follows:
-
IDSLBACWRITEARRAY: Each array component of the user security
label must be equal to the array component of the data security label
to allow access to data.
-
IDSLBACWRITESET: Each set component of the user security label
must include the set component of the data security label to allow
access to data.
-
IDSLBACWRITETREE: Each tree component of the user security
label must include at least one of the elements in the tree component
of the data security label (or the ancestor of one such element) to
allow access to data.
Exemptions
Exemptions provide a way to allow users to bypass one or more access rules
for a security policy. If a user holds an exemption on a particular rule
of a particular security policy, that rule is not enforced when the user
tries to access data protected by that security policy. A user can hold
multiple exemptions. If the user holds an exemption to every rule used by
a security policy, then the user will have complete access to all data
protected by that security policy.
An exemption can be created by DBSECADM as follows:
GRANT EXEMPTION ON RULE IDSLBACREADSET FOR MegaCorp TO 'john';
GRANT EXEMPTION ON RULE ALL FOR MegaCorp TO 'susan';
|
How security labels are compared
When a user tries to access labeled data, his LBAC credentials are
compared to security label protecting data to see if access is allowed. A
user's LBAC credentials are any security labels he holds plus any
exemptions that he holds.
Security labels are compared component by component. If a security label
does not have a value for one of the components, then an empty value is
assumed. As each component is examined, the appropriate IDSLBACRULES are
used to decide if access is allowed. If any of the access rules are
violated, the user is denied access to data. If the user holds an
exemption for the rule that is being used to compare two values, then that
comparison is not done (in other words, access rule is not applied for
that component).
Table 1. Access rules for various
components in a security label
| Type of Access | Component | Access rule to be applied | Access is denied when |
|---|
| Read | ARRAY | IDSLBACREADARRAY | The value of array component in user security label is lower than
the array component in data's security label. | | Read | SET | IDSLBACREADSET | There are one or more protecting
values that the user does not hold. | | Read | TREE | IDSLBACREADTREE | None of the user's values is equal to or an ancestor of one of the
protecting values. | | Write | ARRAY | IDSLBACWRITEARRAY | The user's value is higher than the protecting value or lower than
the protecting value. | | Write | SET | IDSLBACWRITESET | There are one or more protecting values that the user does not
hold. | | Write | TREE | IDSLBACWRITETREE | None of the user's values is equal to or an ancestor of one of the
protecting values. |
Data protection
Data in a table is said to be protected when the table is associated with
a security policy and either rows, columns, or both are protected by
security labels. Data in a table can only be protected by security labels that
are part of the security policy protecting the table. Data protection,
including adding a security policy, can be done when creating the table or
later by altering the table. A table can be associated with only one
security policy. When a protected table is accessed, IDS enforces two
levels of access control. The first level is the traditional Discretionary
Access Control (DAC). That is, IDS verifies whether the user attempting to
access the table has been granted the required privileges to perform the
requested operation on that table. The second level of access control is
Label-Based Access Control (LBAC), which can be at the row level, column
level, or both.
-
Row-level protection: A table can be protected with row-level
protection granularity by attaching a security policy to the table and
by specifying the column where the row security label will be stored.
IDS has introduced a new data type, IDSSECURITYLABEL, for storing row
security labels. Security labels are associated with rows (stored in
IDSSECUIRTYLABEL type column) when rows are inserted into table or
during alter, where the default security label specified is applied to
all existing rows in the table. Row security labels can be modified by
updating the row and specifying new security label for the
IDSSECUIRTYLABEL type column. A table can have at most one column of
type IDSSECURITYLABEL.
A row-protected table can be
created as follows:
Listing 6. Create a row-protected label
CREATE TABLE employee
(lbl IDSSECURITYLABEL, id int, name char(25), ssn char(15)) SECURITY
POLICY MegaCorp;
ALTER TABLE department ADD
(lbl IDSSECURITYLABEL DEFAULT ‘director’), ADD SECURITY POLICY MegaCorp;
|
-
Column-level protection: A database can be protected with
column-level protection granularity by attaching a security policy to
such table and by attaching a security label to one or more columns of
that table. When a column is associated with a security label, that
column is referred to as a protected column. Column security labels
cannot be modified. The existing security label for the column will
have to be disassociated and a new security label attached if column
security label is to be modified. A table can have any number of
protected columns.
A column-protected table can be created
as follows:
Listing 7. Create a column-protected table
CREATE TABLE employee
(id int, name char (25), ssn char(15) COLUMN SECURED WITH manager)
SECURITY POLICY MegaCorp;
ALTER TABLE department MODIFY
(budget decimal(15,2) COLUMN SECURED WITH director),
ADD SECURITY POLICY MegaCorp;
|
|
Built-in security label functions
IDS provides three built-in SQL functions for dealing with security
labels:
-
SECLABEL_BY_COMP: This function
builds a security label (internal encoded representation) by
specifying a security policy and values for each of the components in
the label. The return value has a data type of IDSSECURITYLABEL. This
function is used in insert and update operations to provide the row
security label for a data row.
Listing 8. SECLABEL_BY_COMP function
INSERT INTO employee VALUES
(SECLABEL_BY_COMP('megacorp', 'Secret:
(Product Development,Quality Assurance):Europe', 1,
'Manoj', '123-45-6789');
UPDATE employee SET lbl = SECLABEL_BY_COMP
('megacorp', 'Public:Marketing:Americas') WHERE id = 2;
|
-
SECLABEL_BY_NAME: This function
builds a security label (internal encoded representation) by
specifying a security policy and the name of a security label that is
part of that security policy. The return value has a data type of
IDSSECURITYLABEL. This function is used in insert and update
operations to provide the row security label for a data row.
Listing 9. SECLABEL_BY_NAME
function
INSERT INTO employee VALUES
(SECLABEL_BY_NAME('megacorp', 'manager', 3, 'Lynette', '987-65-4321' );
UPDATE employee SET lbl = SECLABEL_BY_NAME
('megacorp', 'director') WHERE id = 4;
|
-
SECLABEL_TO_CHAR: This function
returns a string representation of the values that make up a security
label. This function is used in select operations to retrieve the row
security label column. It can be thought of as the reverse of
SECLABEL_BY_COMP.
Table 2. SELECT SECLABEL_TO_CHAR('megacorp', lbl), id FROM
employee;
examples
| LABEL | id |
|---|
| 'Secret:(Product Development,Quality
Assurance):Europe' | 1 | | 'Public:Marketing:Americas' | 2 | | 'Confidential:Finance:UK' | 3 | | 'Secret:(Product Development,Quality
Assurance):USA' | 4 |
Conclusion
In this article, you've explored how you can use the IDS LBAC feature to
deploy fine-tuned policy controls. Label-based access control provides you
with a method to have complete control on who can access the data in a very
granular way. You can deploy the LBAC infrastructure easily, and you can
fine-tune it to match the need of the most demanding security
environments, such as government or defense.
Resources Learn
Get products and technologies
Discuss
About the authors | 
| | Lynette Adayilamuriyil is a software engineer and has worked on IBM Informix Dynamic Server for the past nine years. She has vast experience in kernel and security areas of IDS. |
| 
| | Manoj Mohan is a software engineer working on IBM Informix Dynamic Server for the past nine years. He has vast experience in networking and security areas of IDS. |
Rate this page
| |
