The Linux Security Module patches have been having a rough time of it
recently. The latest indignity came along when Christoph Hellwig noticed the sys_security() system call
and promptly sent out a patch to remove it.
sys_security() is defined as:
int sys_security(unsigned int id, unsigned call,
unsigned long *args);
Its purpose is to allow security modules to provide specific services
without the need to register their own system calls. In the case of
SELinux, sys_security() replaces what would otherwise be 52
different system calls.
So why remove sys_security()? There are two reasons, both
relating to a dislike of ioctl()-style calls. This style of call
uses an integer parameter (call, in this case) to choose between
several different operations; the arguments passed in are different for
every operation and have no well-defined type or meaning. This type of
system call argument creates problems for certain architectures, especially
those which have a 64-bit kernel space and a 32-bit user space (such as the
Sparc). On such systems, system call parameters must be converted between
the two views of the world, and there is no way to reliably do that
conversion if the types of the arguments are not known.
But even without that issue sys_security() would be in trouble.
This sort of "multiplexor" system call allows modules to add almost any
sort of functionality imaginable, without any sort of review. That freedom
leads to inconsistent messes, as is the case with many ioctl()
calls, or to the addition of functionality that perhaps should not be
The word from the kernel developers seems to be that each security module
which needs system calls should register them separately. That way each
system call can be judged on its own merits. This approach partially
defeats the purpose of the LSM patch, which was intended to make security
regimes interchangeable. But the kernel developers, many of whom do not
much like the LSM patch to begin with, seem willing to pay that price.
to post comments)