Exceptions to system call masks

------------------------------------------------------

The main weapon of sysmask is to selectively mask access to kernel system
calls. However, Linux actually defines more than 200 system calls. While in
order to keep the use of sysmask as simple as possible, no more than 32
masks are provided to mask these calls. Inevitably, some masks will act on
dozens of system calls each. In the worst case (nonstd), more than 70 system
calls are masked by one single mask.

The big problem is that if a process legitimately uses one of the many
system calls masked by a mask, this mask cannot be set and all the rest will
be accessible to the process, and the drop in security is non-negligeable.
However, in most of the cases only one or two rarely used system calls are
really called by the process, and the sysmask exceptions are there to pick
them out.

In a mask declaration, you may add words that start with the letter 'x',
followed by the number or name of a system call to put into exception. For
example, the following masks everything within nonstd except sendfile64:

	mask=nonstd,xsendfile64

As the system call is of number 239, the following does exactly the same.

	mask=nonstd,x239

Any sytem call can be put to the exceptions, although an exception has no
effect on system calls that are not masked otherwise.

Also, the following declaration is bad, because the whole declaration takes
no effect as the "ipc" call masks only one system call:

	mask=ipc,xipc

The following makes sense (the use of xipc allows simplification of the
declaration), but it is not optimal:

	mask=all,xipc

It is better be replaced by the following which has the same effect.

	mask=all,noipc

---------------------------------------------------------

In order to discourage people trying to make things too complicated, up to
only 4 exceptions can be declared for each process. If you try to put more,
the exceeding declarations are ignored.

Also, the use of exceptions must obey the general rule that a modification
to an existing mask setup cannot allow the process to gain more access
rights. This means that an already masked system call cannot be excepted in
a later modification of mask. On the other hand, exceptions declared at the
same time of a mask containing them are accepted.

Triggers have no effect on exceptions. If an exception is declared within a
triggered mask, the exception takes immediate effect (when this is allowed),
rather than being put into a latent position.

---------------------------------------------------------

There is also a special exception, "xdaemon", that can add great
flexibilities to a token definition because it allows the daemon to
selectively allow or deny exceptions, in the same way as for file or socket
accesses, using the "call" configuration file. Of course, here the number of
exceptable system calls is no longer limited, but xdaemon itself takes up
one place among the 4 exceptions.

For example, the following mask definition in a token sends everything to
the call configuration for access control.

	mask=all,xdaemon
	
Again by the strict security rule, xdaemon is accepted only when the active
m1 mask set of the process is empty. This is always the case for the initial
mask setup of a system token, because a process can only land there via a
token switching.

It is much less true for user tokens, because system tokens are often
imposed before a user token. In this case, only the system administrator can
tell which user he allows to use xdaemon. Those allowed should have a system
token that already sets xdaemon exception. Of course, in this case the
system token configuration should carefully define the call file. A system
call not accepted by the call file of the system token will not be
accessible by the user, even if the latter uses a user token whose
definition allows this call.