Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security

Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security
Toshiharu Harada Takaaki Matsumoto
NTT DATA CORPORATION

Abstract: Mandatory Access Control (MAC) is a powerful guard against non-authorized access, but is vulnerable to
hackers logged in through proper procedure. This paper describes how to guard such case using MAC.
Keywords: Mandatory Access Control, MAC, Login Authentication, Anti-Spoofing

1. Introduction
The DAC (Discretionary Access Control), which 2. Vulnerabilities of Login Authentication
Microsoft Windows, Linux and many other operating The general method of login authentication used in
systems have built-in, holds vulnerabilities and there are many computer systems is password authentication that
risks caused by DAC's vulnerabilities. To solve DAC's uses password supplied by user. Typically, login
problem, MAC (Mandatory Access Control) was invented authentication can be performed only once. Therefore,
[1]. At first, the MAC was implemented for the systems login authentication always has threats such as password
that have special requirements including military use. But cracking using dictionary attack or avoidance of login
LSM [2] (a framework to provide MAC to Linux) and authentication by attacking authentication program's
SELinux [3] (one of implementations that provides MAC vulnerability (for example, buffer overflow).
using LSM) were introduced into Linux (the open sourced Conventional login authentication has the following
operating system) on November 2004, and the MAC problems.
became closer to us at a stretch. While the environment to ・ Login authentication can be performed only once.
build secure Linux system has been greatly improved, the ・ Passwords are used in many systems.
purpose and meaning of security enhancement by ・ Have to worry password's secrecy because you can't
introducing the security enhanced OS are not very know the moment your password being cracked.
accurately known. According to a paper [4] by SELinux ・ Have to worry vulnerability of authentication
development project, the following two are the merits of programs.
introducing SELinux. These problems are described below.
・ Handling of the threats posed by "Tampering" or
2.1. Login authentication can be performed only once.
"Avoidance of security mechanisms at application
level". Normally, the login authentication is performed only
・ Minimizing the damage caused by malicious or once before a user logs into the system, regardless of the
vulnerable applications. user is system administrator or not. Some security aware
These are the exactly merits gained by security applications (for example, database software) enforce
enhancement at OS level. These are never excessive application specific authentications, but users can access
requirements and all computer systems should provide to almost all resources if they passed the login
essentially. But you need to be careful that the authentication. There are some attempts to notify the
introduction of MAC itself doesn't promise protection possibility of illegal logins (for example, displaying last
against all kinds of damage. On the systems that have login time) after the user passed the login authentication.
MAC support, if MAC's policies are defined appropriately, But even if the user can notice illegal logins, it's useless
the system won't get damaged indefinitely by invoking because the system is already damaged and the user can't
shell with administrator's privilege even if some process is respond. Moreover, the user even can't identify the
hijacked due to vulnerability such as buffer overflow. But damaged range of the system after the fact.
since it is possible to log into the system through proper
2.2. Passwords are used in many systems.
procedure (for example, login authentication using valid
username and correct password), there is a threat that a The only basis of password authentication is the
cracker logs into the system in case the password's secrecy correctness of the ordering of password string. Therefore,
is broken. It is possible to define strict policies for routine it is problematic that users have to keep their password's
tasks and functions. But it is difficult to define strict secrecy. Possible risks are, cracked by dictionary attack,
policies for administration task that is done by stolen by eavesdropping or social engineering. It is
administrator logged into the system. In SELinux, it is possible to reduce these risks by introducing special
possible to define policies that deactivate root privilege [5], systems (for example, one-time passwords, biometrics),
but there remains an interface to modify and reflect but they are costly because administrators have to
policies, and the interface is protected by conventional introduce special devices or special software.
password authentication after all. This paper describes
2.3. Have to worry password's secrecy.
how to prevent crackers from logging in through proper
procedure using MAC, using TOMOYO Linux (one of MAC It is possible to detect that user's passwords are
implementations which the authors of this paper attacked (for example, using dictionary attack) by
(hereafter, we) have originally developed). monitoring authentication failure log. But you can't

answer to the following questions. MAC, but has significant points on OSes that support
"How many days does the cracker need to find my MAC, for OSes that support MAC can enforce the
correct password?" (In other words, "When is the last day I multiplexed login authentications.
can use my password safely?")
"Changing my password ALWAYS makes things safer, 4. Login Authentication Multiplexing
for I found an attempt to crack my password?" (In other
4.1. Image of multiplexing
words, "Changing my password ALWAYS makes the
cracker need more days to crack my password?") The Fig. 1 shows the conventional login authentication,
There are discussions about "Password aut hentication and the Fig. 2 shows the multiplexed login authentications.
and pass phrase authentication, which one is stronger?"[6], The purpose of login authentication is to prevent crackers
but neither password authentication nor pass phrase from reaching to the castle.
authentication can answer to these questions after all. Fig. 1 creates a hole and places a guard. The guard
Operations that forces users to change their passwords so means a program that performs authentication. There is
frequently makes their passwords easier and, as a result, only one wall. Without MAC, the wall could be broken and
will lead to insecure system. the cracker can reach to the castle without passing the
guard (i.e. the cracker can log into the system without
2.4. Have to worry vulnerability of authentication
passing login authentication).
programs. By introducing MAC, the wall becomes unbreakable (i.e.
Even if you introduced recently spreading special the cracker can't log into the system without passing login
devices (such as fingerprint authentication, iris authentication). But since there is only one guard, the
verification), the authentication might be avoided if there cracker can reach to the castle if the cracker could pass
is vulnerability (such as buffer overflow) in the program the login authentication through proper procedure (using
that handles these devices. valid username and correct password).

3. Security Enhanced OS
3.1. The concept of security enhancement at OS level.
The MAC is capable to forbid execution of unnecessary
functions by controlling OS's behavior, although OSes are
originally made available for generic purpose. The MAC's
access control is applied to all processes and all users
without exception, and can precisely restrict resources
such as files and directories that processes and users can
Login
access. In normal Linux, DAC's access control is not Authentication
applied to the system administrator (i.e. root). In general, (Built-in)
an OS that supports MAC is called "Security Enhanced
OS"[3].
Fig. 1 Conventional Login Authentication
The reason why security enhanced OS is helpful is
described below with a simple example. Processes that
Fig.2 inserts two walls between the original wall and
provide services over network (such as ftp server, samba)
the castle, each wall has one hole and one guard. The
are always configured to accept request from network. The
cracker has to pass all guards to reach to the castle.
crackers can hijack these processes and invoke shell with
administrator's privilege if vulnerability exists in these
programs. OSes that don't support MAC cannot prevent
the invocation of shells or invocation of malicious Second Extra
commands from the invoked shells. But if MAC is Authentication
supported and appropriate policies are defined by
administrators, the OS can prevent the invocation of
shells that are essentially unnecessary for these processes
if the processes are hijacked.

3.2. Reinforcement of login authentication using security First Extra
Authentication
enhanced OSes Login
Authentication
In general, the security enhanced OSes are introduced
(Built-in)
to reduce the damage of hijacking and to ensure the data
integrity. But the login authentication can produce
unexpected pitfalls, as described above. However, it is Fig. 2 Multiplexed Login Authentications
possible to solve this problem using MAC that securit y
enhanced OSes support. The basic idea is "Multiplex the 4.2. Example programs for extra authentication
Login Authentications". The login authentication You need to place newly developed authentication
multiplexing itself is possible to OSes that don't support

programs for First and Second Extra Authentications
shown in Fig. 2. Some examples using shell scripts are Typically, the system looses protections against crackers
shown below. But you should develop your programs using when the cracker successfully passed conventional login
non-scripting (for example C) language for production authentication. But you can counter this threat by
environment, for the content of shell script program is introducing extra authentications with various
exposed if the environment variable "SHELLOPTS" is set authentication rules and enforce them using MAC.
with "verbose" flag.
5. Advantages of Login Authentication Multiplexing
(1) Simple password authentication The following merits are derived by login authentication
This program (Fig. 3) requires "SAKURA" as multiplexing.
password. The authentication fails if the user entered
5.1. You can enforce login authentication for arbitrary
wrong password for 3 times.
times.
#! /bin/sh You can enforce login authentication for arbitrary times
for i in 1 2 3 depending on the resource's importance. For example, you
do can allow access to trivial resources after passing only
read -r -s -p 'Password: ' passwd conventional login authentication and allow access to
echo critical resources after passing three extra login
[ "$passwd" = "SAKURA" ] && exec $SHELL authentications.
done
5.2. You needn't to worry about vulnerability of
echo 'Incorrect password.'
authentication programs.
Fig. 3 Simple password authentication The vulnerability of authentication program is critical if
the authentication can be performed only once. But since
(2) Non-password authentication you can enforce multiple different authentications, it
This program (Fig. 4) authenticates the user by the won't matter so much if one of the authentication
existence of the file /data/rootauth . This program prompts programs has vulnerability.
users to enter password, but that is a dummy. The
5.3. You can use everything for authentication
authentication always fails whatever passwords the
cracker guesses unless the file exists. The file needs to be Regarding conventional login authentication, the
created (using touch commands, for example) prior to the system can't know the process of supplying passwords and
execution of this program. (Since a terminal is supplied to the authentication program authorizes the user using the
the user after the conventional login authentication, the supplied passwords. But after the conventional login
user can execute necessary command if granted by the authentication, a terminal (or a console) environment is
policy.) provided to the user. This means that the authentication
programs can know the user's behavior in great detail. You
#! /bin/sh can use not only password strings but also all elements for
for i in 1 2 3 authentication, for the authentication programs can know
do (for example) the speed of key typing or the user's
read -r -s -p 'Password: ' passwd behavior after the conventional login authentication and
echo can use these elements for authentication.
[ -f /data/rootauth ] && exec $SHELL Another example, you can use the existence of specific
done files (Fig. 4) or the contents of specific file as a password.
echo 'Incorrect password.' You can use flags that always fail the authentication
request like /etc/nologin , last modified time of specific file
Fig. 4 Non-password authentication to test "Whether this authentication is started within 1
minute from the previous authentication".
(3) Never succeeding authentication The programs that perform authentication even needn't
This program (Fig. 5) prompts users to enter passwords, to be recognized at a glance that the programs are used for
but never succeed. This program is not for legal users, but authentication. For example, a screen like card games
for crackers who don't know how to pass this appear when the program is executed and actually users
authentication. This program will confuse crackers. can play with, but the authentication succeeds only when
the specific key is pressed at the specific timing (like a
#! /bin/sh kind of trapdoor programs). The requirement is that
while : authentication programs are programs that only the legal
do users know the procedure how to pass that authentication.
read -r -s -p 'Password: ' passwd You can create authentication programs in the same
echo manner of developing normal application programs. Your
done idea makes strong authentication and the possible
combinations of elements are infinite.
Fig. 5 Never succeeding authentication

user's behavior so that only operations that are necessary
5.4. No damage unless all authentications are penetrated.
to pass the next authentication are allowed using MAC's
You can define policies that forbid access to critical policy; to prevent subversive acts unless the cracker
resources unless the user passes all login authentications. succeeds all login authentications. Therefore, programs
Specifically define policies that allow users who passed that invokes login shell in "batch mode" ("scp" connects to
one login authentication do minimum operations that are remote host using "ssh" and invokes remote host's login
needed to pass the next login authentication. You may shell with "-c scp arguments" options. "sftp" connects to
append policies that allow users to execute dummy remote host using "ssh" and invokes remote host's login
authentication program (like Fig. 5) to make penetration shell with "-c /usr/libexec/openssh/sftp-server" options.)
more difficult. can't recognize the extra login authentications; i.e. you
can't use login authentication multiplexing for "scp" and
5.5. You can advise to legal users.
"sftp". This means that resources that are accessible
You can know which authentication program was become vulnerable if the cracker passes ssh's login
penetrated, and you can replace only the program that authentication.
was penetrated. The solution is that restrict resources that are
You can notify to users by sending mail like "The login accessible to such programs. Specifically, define policy
authentication of host XXXXX was penetrated, but the that limits reading/writing to specific temporal directory,
cracker was eliminated by extra authentication and move data between the specific temporal directory and
mechanism. To prevent another penetration, I changed the other directories from shells that are invoked after all
your password to XXXXXXX." extra authentication are succeeded.

6. Practical Issues and Solutions 7. Implementation using TOMOYO Linux
6.1. Login shell 7.1. About TOMOYO Linux
Login shell is a program that is executed when a user TOMOYO Linux is one of MAC implementations that we
logs into the system, and is specified in the /etc/passwd file. have developed based on vanilla Linux kernels, and has
In Linux, bash, ksh, tcsh, zsh etc. are available. "accept mode" that helps administrators defining MAC
Shell is provided to execute external programs, but most policies. Please refer to document [7] for abstract, and
shells have their internal (built-in) commands. document [8] for implementation.
An example of shell's internal commands is "kill", which TOMOYO Linux defines DOMAIN (the unitary of
sends signals to processes. A cracker who passed the login granting ACLs) based on the process's invocation history,
authentication can forcefully terminate arbitrary proce ss and lists ACLs that are allowed to each DOMAIN. The
if appropriate privilege is given. ACL consists of the access mode (read/write/execute) and
Of course, it is possible to restrict signal transmission the pathnames. For example, define the following line to
using MAC's policy. But that is not enough. allow /bin/bash which are invoked by /usr/sbin/sshd (i.e. a
A cracker can give high load using infinite loop using user logged into the system using ssh) to read /etc/passwd
shell's internal command. For example, if the cracker and execute /usr/bin/scp .
gives internal command "while : ; do echo ; done" to bash,
the system's response become slower. It is impossible to <kernel> /usr/sbin/sshd /bin/bash
prevent this CPU consumption attack by infinite loop
using MAC's policy. 4 /etc/passwd
Therefore, to apply this login authentication 1 /usr/bin/scp
multiplexing method, it is important that login shells
don't have unnecessary internal commands. The role of The integer before pathnames corresponds to UNIX's
login shells is to provide interface to execute the next permission. For example, "4" is "r--", "1" is "--x", "6" is
extra authentication. Less functional shells are better and "rw-", and "7" is "rwx". The name of DOMAIN starts with
suitable. Of course, you can use normal shells to start <kernel> , and the program's pathname is concatenated to
actual operations after passing all login authentications. the name of DOMAIN where the program is invoked. For
example, the name of DOMAIN for /bin/tcsh that is
6.2. "scp" and "sftp"
invoked by /bin/bash that is invoked by /usr/sbin/sshd (i.e.
There are two commands that are frequently used for a user logged into the system using ssh and invoked
server maintenance purpose, "scp" and "sftp". But it is /bin/tcsh from the login shell) is represented as follows.
impossible to apply this login authentication multiplexing
method for these programs. The reason and solutions are <kernel> /usr/sbin/sshd /bin/bash /bin/tcsh
described below.
A shell has two operation modes, one is "interactive The granularity of TOMOYO Linux's access mode is not
mode" that prompts and waits for user's input, the other is high as SELinux. But since you can define policies using
"batch mode" that are invoked with "-c command list" pathnames, it is easy to understand for administrators
command line parameter and process the given command who have standard administration skill. And since
list and then terminates. The method this paper describes DOMAIN is divided by invocation of a program and the
invokes login shells in "interactive mode" and restricts ACLs are given for 1-file-at-a-time, you can specify more

precisely than SELinux. 1 /bin/candy

7.2. Actual example policy
<kernel> /usr/sbin/sshd /bin/falsh /bin/honey /bin/falsh
This section describes an actual example policy of login /bin/falsh /bin/candy
authentication multiplexing shown in Fig. 2. To help 1 /bin/falsh
understanding, miscellaneous files like library files are
omitted. The scenario for this policy is the following. <kernel> /usr/sbin/sshd /bin/falsh /bin/honey /bin/falsh
・ Login using ssh and invoke (our custom made shell) /bin/falsh /bin/candy /bin/falsh
/bin/falsh as the login shell. /bin/falsh has no built -in 1 /bin/bash
commands like "kill" or "while" to prevent attacks (for
example, killing processes, infinite loop) using login <kernel> /usr/sbin/sshd /bin/falsh /bin/honey /bin/falsh
shells. /bin/falsh /bin/candy /bin/falsh /bin/bash
・ Invoke (our custom made authentication program)
/bin/honey (which corresponds to First Extra In addition to this, register the DOMAIN "<kernel>
Authentication in Fig. 2). /bin/honey prompts for /usr/sbin/sshd /bin/falsh /bin/honey /bin/falsh /bin/falsh
password input, but this program checks not only the /bin/candy /bin/falsh /bin/bash" as trusted, and move data
password string but also the time interval each between /data/scp.tmp and other directories from this
letters are typed. The authentication fails if either trusted DOMAIN.
password string or the time intervals (preset in this
7.3. Actual operation
program) don't match.
・ Invoke (our custom made authentication program) This section describes the procedure for users. Fig. 6 is a
/bin/candy (which corresponds to Second Extra screenshot that a user is connecting to a Linux server
Authentication in Fig. 2). /bin/candy prompts for using ssh. In the screenshot, the user enters password
password input, but this program checks not only the strings to log in, as conventional.
password string but also the elapsed time from the
invocation of the parent process. The authentication
fails if either password string doesn't match or the
elapsed time is longer than 10 seconds. (It is difficult
to start /bin/candy after the invocation of /bin/honey
within 10 seconds, for /bin/honey needs a several
seconds. Therefore, /bin/falsh is inserted between
/bin/honey and /bin/candy to reset the invocation time
of the parent process.)
・ Since "scp" and "sftp" need to be executed from login
shell, the policy allows executing these programs from
login shell, but these programs can access to only
/data/scp.tmp directory.

<kernel> /usr/sbin/sshd /bin/falsh

1 /bin/honey
1 /usr/bin/scp
1 /usr/libexec/openssh/sftp-server
Fig. 6 Conventional login authentication

<kernel> /usr/sbin/sshd /bin/falsh /usr/bin/scp
After the user passed ssh's login authenticatio n, invoke
"/bin/honey /bin/falsh /bin/candy" in this order (as defined
6 /data/scp.tmp/¥*
in the policy) and precede the authentication. Fig. 7
<kernel> /usr/sbin/sshd /bin/falsh contains authentication failures intently to show that the
/usr/libexec/openssh/sftp-server extra login authentications aren't simple password
authentications. Also, the passwords supplied are visible,
for this is a demonstration.
6 /data/scp.tmp/¥*
In the first attempt of /bin/honey , the user entered the
correct password, but the authentication failed since the
<kernel> /usr/sbin/sshd /bin/falsh /bin /honey
1 /bin/falsh typing interval was inappropriate. In the second attempt
of /bin/honey , the user entered the correct password with
appropriate typing interval, and the authentication
succeeded.
1 /bin/falsh
In the first attempt of /bin/candy , the authentication
failed due to incorrect password. In the second attempt of
/bin/falsh /bin/candy , the user entered the correct password, but the

authentication failed since /bin/candy has to be invoked
within 10 seconds after the shell (/bin/falsh) starts. In the
third attempt of /bin/candy , the user entered the correct
password, and the authentication succeeded since
/bin/candy is invoked within 10 seconds after /bin/falsh
starts.

Fig. 8 Stuffing all passwords into one field

On the contrary, the way of multiplexing needn't to
change the password field when the authentication
method changes, for passwords are supplied on each step
like Fig. 6 and Fig. 7. This means you needn't to change
existent protocols and PAM configurations.

8.2. Elements available for authentication
Fig. 7 Extra login authentications
Regarding conventional login authentication, the
system can't know the process of supplying passwords and
After the user passed /bin/candy (i.e. the user has
the authentication program authorizes the user using the
reached to the castle in Fig. 2), invoke /bin/bash and start
normal operations. supplied passwords. But by introducing login
authentication multiplexing, the authentication programs
can know (for example) the speed of key typing or the
8. Discussion
user's behavior after the conventional login authentication.
8.1. Comparison with PAM This allows you to choose your favorite elements from
infinite number of elements to create customized login
It is possible to perform multiple authentication
methods using PAM (Pluggable Authentication Modules) authentication.
to reduce the risks of illegal login. But if PAM itself has 8.3. Burden increment on users
vulnerability, the login shell could be started before
It is acceptable to provide multiple information for
performing all authentication modules specified as
authentication on the systems that worth protecting from
"requisite".
penetration by providing extra information other than
Also, there are typically only two input fields (username
and password) like Fig. 6, it is impossible to use multiple password for authentication.
passwords using PAM provided by the system. Therefore, Our method is just supplying one information on each
authentication instead of supplying all information at
people combine with other methods that use infor mation
once. In the view of users, only the timing of supplying
other than password; for example, hours checking
information is changed. There is no limitation for extra
(pam_time.so) and the name of terminal device
authentication program, so you can choose one that the
(pam_securetty.so).
If you WANT to use multiple passwords, you have to users feel minimum burden.
stuff all passwords into one input field, splitting by 8.4. Price for paying for login authentication reinforcement
column number like Fig. 8. B ut the way of splitting
Our method doesn't cause overall damage if there is
password field (the way of interpretation) changes
vulnerability in one of the authentication programs. You
whenever new elements are stuffed into password field.
can improve security for login authentication dramatically
This means you need to negotiate with all modules that
share password field. with just tens of lines code in C language.

8.5. Security Stadium 2004
We attended at Security Stadium 2004 held by JNSA on
the defense side. We announced root's password so that
the offence side can login via ssh (without cracking sshd).
We received attacks by security experts, and turned out

that our method is very effective. Please refer to document n.pdf
[9] for details. [9] Security Stadium 2004 (Written in Japanese)
http://www.jnsa.org/active/press/vol12pdf/4_report4.pdf
8.6. Applying to OSes that doesn't support MAC
It is possible to perform multiplexed login Notes
authentications for OSes that don't support MAC. But
since the behavior of authentication programs can't be This is a translation of the original paper, which was
restricted from outside using MAC's policy, each written in Japanese and published in Workshop on
authentication program has to restrict its behavior, and
Informatics 2005 held in Japan. You can obtain the
developers have to be very careful not to create security
loopholes. If MAC is supported, the behavior of original paper from the following URL.
authentication programs are restricted from outside using
MAC's policy, and developers can easily develop http://sourceforge.jp/projects/tomoyo/document/winf200
authentication programs without worrying security 5.pdf
loopholes. Therefore, our method has significant points on
OSes that support MAC. TOMOYO Linux was released on November, 11, 2005.
You can get more information at the following URLs.
9. Conclusion
The security enhanced OSes are invented to protect http://tomoyo.sourceforge.jp/
from unauthorized access and leakage of information, and http://sourceforge.jp/projects/tomoyo/
are getting to spread. It is possible to reduce the risk of
hijacking due to vulnerability such as buffer overflow and
improve system security by defining appropriate policy.
But how well access to system resources is controlled, the
dependence on the password login authentication can
produce unexpected pitfalls. The method of login
authentication multiplexing described in this paper is
easy to implement and doesn't require one-time passwords
or costly biometrics technology.
Acknowledgment: We were supported from the
technological study to implementation and evaluation on
TOMOYO Linux by Tetsuo Handa, NTT DATA
CUSTOMER SERVICE CORPORATION. We would like to
thank Mr. Handa.

Bibliography
[1] "A research on information systems for e-Government
based on OSes with well-considered security" (Written in
Japanese)
http://www.bits.go.jp/inquiry/pdf/secure_os_2004.pdf
[2] Linux Security Modules
http://lsm.immunix.org/
[3] National Security Agency, Security-Enhanced Linux
http://www.nsa.gov/selinux/
[4] “Meeting Critical Security Objectives with
Security-Enhanced Linux”
http://www.nsa.gov/selinux/papers/ottawa01-abs.cfm
[5] SELinux Play Machines
http://www.coker.com.au/selinux/play.html
[6] Pass Phrases vs. Passwords
http://www.microsoft.com/technet/community/columns/s
ecmgmt/sm1004.mspx
[7] Toshiharu HARADA, Takashi HORIE and Kazuo
TANAKA, "Towards a manageable Linux security." Linux
Conference 2005
http://sourceforge.jp/projects/tomoyo/document/lc2005-e
n.pdf
[8] Toshiharu HARADA, Takashi HORIE and Kazuo
TANAKA, "Task Oriented Management Obviates Your
Onus on Linux." Linux Conference 2004
http://sourceforge.jp/projects/tomoyo/document/lc2004-e

Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security (20)

More from Toshiharu Harada, Ph.D (20)

Recently uploaded (20)

Chained Enforceable Re-authentication Barrier Ensures Really Unbreakable Security