Browse Prior Art Database

Method of controlling database data and data access via shared memory between database and security application

IP.com Disclosure Number: IPCOM000237071D
Publication Date: 2014-May-29
Document File: 3 page(s) / 57K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method for controlling database data and data access via shared memory between the database and a security application is disclosed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 01 of 3

Method of controlling database data and data access via shared memory between database and security application

Database data collection and data access control can be implemented by intercepting system calls in the kernel. However, intercepting the system calls is platform and version dependent, and it has to synchronize with other kernel modules which also intercept the system calls, in addition, it can not deploy the data level control for encrypted the data. Shared memory has been used for inter-process or machines communication at many purposes, however, shared memory has not been used to deploy data level access control to the database by ruling collected data from the database.

Disclosed is a method for controlling database data and data access via shared memory between the database and a security application.

A library built with two shared memory communication schemes may be implemented to handle all activities of creating, accessing, reading, writing, locking the file backed shared memory region. The database could have an option to pre-load the library from the security plugin. The security plugin is used to access the shared memory area, write to and read from the database Support is provided in the library for database activities, to read control flags to deploy data level access, such as blocking certain activity or forcing termination of the session. The application with the library statically linked will first create/open a new/existing shared memory, and read the database activities from the shared memory, then pass them to a security engine. The security engine will send a control flag to the application according to the ruling setup. Finally, the application will write the control flags to the shared memory for the database to read and apply the control to the session.

The Figure below depicts a library implemented with two shared memory communications schemes("shmem", "shmbox"). Both schemes will use a file backed shared memory region.

1


Page 02 of 3

Figure

The first shared memory communication scheme (shmem) is used for communication from database to application.

The theory of "shmem" operation:

Database passes a bunch of buffers that need to be queued up for application to read. Application will read these buffers and pass it to a security engine to get data control back. In order to copy these buffers as few times as possible from the shmem, it's best to be able to use them directly from the shmem region. Because of that, the data portion of the buffer (after the length and complete flag) needs to be aligned on an 8 byte boundary. Since the flag and length are 4 bytes each, it is sufficient to align the start of each buffer on an 8 byte boundary and ensure that the total length of the queue is a multiple of 8 bytes.

This is how the data looks in shmem: [ HEADER ] [ DATA ], Where header is the shared memory structure (padded to be a multiple of 8 bytes in length) describing the DATA queue. Data has elements:...