Customized user authentication schemes based on sysmask

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

Sysmask implements interactive security control. This means that the access
control is not a static definition based on the identity of the process. It
is rather dynamic, based on the actions taken by the process.

Such actions may be a file access (read, write, execution, stat, unlink),
access to a particular system call, or a network access. Depending on the
actions, the system knows what the process is doing or is trying to do, and
appropriate actions can be taken against the process.

This is particularly interesting when the process is an interactive shell.
In this case, the security reaction can be made to depend on the actions
taken by the user. And such a reaction includes token switching which may
bring about the removal of some existing masks.

One can use this feature to define versatile custom authentication schemes.
Token switching after the login (ssh) can deposit the logged user to a
quarantine zone (take a look at the token s10001). The quarantine token may
have as little privilege as the sh method of the security challenge page,
that is, it is practically unbreakable.

Now for example executable files or symbolic links with special names can be
hidden in directories unreadable by ordinary processes (by using denyid).
Each of them may allow processes calling it to gain some privileges, under
precisely defined circumstances (user ids, tokens, masks, syscall number).
Without the possibility to peek into the forbidden directory and without
knowing which circumstances trigger what (the system level configuration of
sysmask is forbidden by denyid), it is extremely difficult for an attacker
landed on the quarantine zone to get access to the triggers.

The triggering action may also be operations on files that do not exist on
the file system. For example, you can easily write a script called "try",
that translates its command line parameters into a fictive pathname. Now
suppose that the user types the following in the command line:

	try math made mun modest

A fictive pathname "/math/made/mun/modest" is created and submitted to the
kernel by the script. If this matches something in the sysmask token
configuration, a token switching might take place. In this case, the phrase
"math made mun modest" becomes a kind of password (or more exactly
passphrase). It is a bit long but is much easier to remember than nowaday's
"secure" passwords, and a phrase is much more difficult to crack than a
word. If each word is chosen within a dictionary of only 1000 words, a
phrase of 4 words makes 10^12 possibilities!

Because of the tight restrictions of the quarantine, an attacker breaking
through sshd can do nothing until he manages to type the good passphrase as
above. That is, the latter becomes a second-layer authentication scheme. And
such a scheme can be installed by the system administrator as well as by an
ordinary user.

Unlike the traditional password system, this scheme is highly adaptable,
with possibilities of variations that are only limited by the imagination of
its creator, usually with no need to develop new softwares. Here we just
give some elementary examples.

To fight against exhaustive cracks, trap phrases can be defined. And you can
easily manage to have much more trap phrases than good passphrases, such
that the attacker with no inside knowledge has much more probability to hit
upon a trap phrase. In such a case, emergency measures can be taken to
prevent further accesses, even if the good passphrase is entered, until a
special "anti-emergency" action is taken to unlock the measure. Now you can
theoretically compute the chance for a cracker to get through, and configure
things to make this chance as small as you like.

Sequencial actions may be required, such as a chdir to a special directory
(existing or not) after entering the passphrase. Or a timer may be
incorporated into the shell script, so that a passphrase entered too quickly
after the first shell prompt or after some other action is always refused.
Now the biggest problem for the cracker is that after a denial, he has no
idea whether the rejected phrase is good or not. Maybe the phrase is good
and the denial is due to some other reasons; so it is useless to try every
possible phrase.

Under a graphical environment, a list of random photos may be presented to
the user who is then asked to click on the familiar face. Or under a text
environment, some randomly generated text may be printed, requiring
knowledgeable replies. Even an extremely rudimentary interactive scheme of
this kind is enough to stall automated cracking.

I have my own customized schemes on my systems. Systems that on some of them
even the root account has an empty (primary) password. Of course I won't
tell what is my scheme; it is very easy for myself, but I don't think
anybody can guess out what I have put there. And if you try everything
possible, you have at least 10^10 more chance to hit my trap. Well, now how
do you define the word "everything"?

I know you are thinking of cracking my communication packages. The system
will never let you in if you repeat my previous method: the authentication
is interactive.