Elektronika 2009-11.pdf - Instytut Systemów Elektronicznych

sys_write=sys_call_table[__NR_write];
sys_call_table[__NR_write]=my_sys_write;
sys_send=sys_call_table[PXX_SEND_ADDR];
sys_call_table[PXX_SEND_ADDR]=my_sys_send;
sys_sendmsg=sys_call_table[PXX_SENDMSG_ADDR];
sys_call_table[PXX_SENDMSG_ADDR]=my_sys_sendmsg;
sys_sendto=sys_call_table[PXX_SENDTO_ADDR];
sys_call_table[PXX_SENDTO_ADDR]=my_sys_sendto;
The service and module exchange their names and software
version. Initialization is done.
In second phase module waits for any application to call
system function open. Disk files are identified by i-node values.
Function which gets i-node value from file descriptor is
shown in listing 2.
static unsigned long get_ino(int fd)
{
unsigned long ino=0;
struct file * f;
}
if (fdf_dentry->d_inode->i_ino;
fput(f);
}
return ino;
A PID number of parent process and it’s father’s is pushed
to the array of PID of applications whose requested opening
protected file.
If any application tries to call any data write function or
send it using socket, kernel module looks for it’s or it’s father
PID in PID array. If found, kernel module sends application’s
PID to daemon, which logs the event. Module rejects to execute
write/send function.
When an application calls close function, it’s PID number
(and it’s father’s PID) are pulled from a PID list.
An array of protected files’ i-nodes (got using absolute
path) is created once when PXX daemon starts. Each path is
parsed to check whether it is correct. After all PXX daemon
fills the protected files structure (listing 3).
struct protected_files
{
unsigned int qty;
ino_t * inos_t;
char ** names_t;
};
An array containing i-node values is taken from protected_files
structure and send to kernel module via netlink
socket.
Difficulties related with implementation
of full functional DLP system for Linux
The discussed solution bases on i-nodes despite of it is neither
perfect one, nor unequivocal. The values of i-node are unique
but only in one filesystem, but there is no better solution.
An experiment drove to some conclusion. One of these
can be an answer to question why there is still no DLP application
to Linux. Most important are discussed below.
It was not possible to write full functional, working in kernel
space function, which can preprocess any path to absolute
path, cause it is impossible to determine caller’s work directory
from kernel space. Another idea is using algorithm implemented
in Tomoyo [6] Linux, which has realpath function, but
also this solution could not be good enough because of hard
links, whose can be wrong interpreted by this function. Apparently
best solution could be mapping file to pair disk-block, but
in filesystem other than “ext” this method could be not well
working because of block suballocation (e.g.: Reiser 4). Block
suballocation is used to more effective management with files
which are smaller than size of block. In filesystem with no block
suballocation occupies one block, so the disk space is wasted.
Block suballocation let keep some small files in single block.
Unfortunately - relation between file and block is ambiguous.
None effective method of blocking the clipboard have been
found. This „tiny” weak point determines the weakness of
whole system. Clipboard works in user space and is managed
by window manager. To block possibility of making copies to
clipboard source of window manager and it’s recompilation is
required. In Windows system it is possible, because there is
only one window manager. Linux users has a freedom of
choice one of many solutions (GNOME, KDE, XFCE etc.)
System does not protect files in situation, when protected
file is opened, then it’s content is saved to memory and after
that file is closed. An effective implementation of protecting
files in such situation were not implemented yet.
Most important problem related with developed system is
it’s disability to work in real-life environment where aggressor
has wide knowledge and suitable tools. For computer
geek who understand idea of DLP system cracking this implementation
is a matter of time. It is important to mention
that aim of this project was implementation of only a stub of
project, which will be developed by more programmers. The
aim was to begin talk about DLP system for Linux and determining
it’s hardest challenges and difficulties caused by
specificity of Linux.
Conclusions
The experiment of implementation DLP system for Linux
could be recognized as successful, but authors feel insufficiently.
The implemented system is not cross-platform and
does not look like it could be soon. Only the implementation
done for specific architecture, kernel version and graphical
interface. Currently it can not be recognized as universal solution
even within single distribution because of unsupported
protection of clipboard.
The hardest thing for DLP system for Linux creator is -
irony of fate - an architecture of Linux. It’s kernel has many
variants, some of distributions (e.g. Ubuntu) provides it’s own
implementation of kernel. The problem is leak of uniform specification
which could describe all the kernels of all distributions.
This is the expression of Linux’s freedom, but on the other
hand - serious hindrance. Often changes in kernel architecture
also are not helpful.
Creating perfect one DLP application for Linux would require
remaking of significant part of Linux Kernel to allow to
“transport” in process information additional flags related with
security. After that only these filesystems could be accepted,
which allow to identify any disk file using uniform value. To get
this idea done, recompilation of graphical environment would
50 ELEKTRONIKA 11/2009