A Biometric Approach to Linux Login Access Control Adam J. Gandossi, Wanquan Liu and Ronny Tjahyadi
Lixin Xu
Department of Computing Curtin University of Technology Perth WA 6102 Australia
[email protected]
School of Mechatronic Engineering Beijing Institute of Technology Beijing 100080 China
[email protected]
Abstract— Login access control refers to securing the entry point to a computing system. The login system is responsible for this service and must provide a number of tasks, the main task being that of user authentication. Traditionally, the authentication in Linux and other operating systems is achieved through password verification. This research focused on overcoming the vulnerabilities of password verification, which has been identified as the greatest gap in computer security, through the development of a biometric (facial recognition) login system. The application of biometrics, the automated use of physiological or behavioral characteristics to determine or verify identity, was applied via the Eigenface algorithm successfully in this research, resulting in a functional prototype biometric login system for Linux. Keywords—Linux operating system, User authentication, Face Recognition, biometrics
I. I NTRODUCTION In any “secured” computing system, the login procedure is the only port of entry, hence login access control plays a crucial role in its security. The login system is responsible for this assurance and must provide a number of tasks, the main task being that of user authentication. Traditionally, the process of authentication has been achieved through password verification which has inherent vulnerabilities which can be easily exploited by the unlawful. Biometrics offers potential automated methods of user authentication, on the principle of measurable physiological or behavioral characteristics. Biometric signatures are essentially unique and difficult to forge, thereby presenting a rational alternative to password systems. Apart from the potential security benefits of using biometrics for the identification of users within a computing system, there are a number of associated convenience benefits, such as the complete automation of the login process and removing the need for users to remember complex passwords, that can be forgotten, or disclosed. Research in the field of system security has acknowledged the potential offered by biometric techniques for providing user authentication. Several biometric login systems already exist within Windows and Macintosh environments [3] via facial recognition [8] and Iris recognition [1]. By the authors’ knowledge, no available biometric login system has been developed for Linux platform today. This is unfortunate as
c 2006 IEEE 1–4244–0342–1/06/$20.00 °
an open source system which could provide the framework needed by researchers to fill one of the most common computer security gaps [7]. Reeder [4] has been developing a fingerprint recognition login system but his efforts remains incomplete due to the complex integration of several components. There exists very little research on the construction and the possible effectiveness of such a system in the existing literature. These issues provide the motivation for this research, which culminates in the benefits of biometrics and applies them to login access control, replacing the traditional techniques for gaining access to a computer system. The main contribution of this paper is to change the authentication system for linux operating system and use two basic face recognition techniques to verify its effectiveness. More advanced authentication techniques can be embedded into this system easily. The paper is organized as below. The system design is explained in section 2. Experiment analysis will be presented in section 3 and conclusions will be given in section 4. II. S YSTEM D ESIGN AND I MPLEMENTATION To adhere to the login procedure followed by the default set of Linux login systems, such as the login command, the system implemented the tasks of authentication and securely allow the user access within the system. In keeping with the project’s objective, to easily plug in alternative biometric techniques, the login system was divided into two parts: authentication management and session management. Authentication management involves the validation of a user to the system, through biometric techniques. Session management provides the mechanisms for assigning authenticated users’ privileges on the system, initializing the users X11windowing session and assigning additional constraints on the user, such as when, and for how long certain users can login to the system. Figure 1 shows a generalization of the defined architecture of the implemented login system (grey shaded box) and how it was deployed into the current Linux architecture. When the computer starts up, the Linux kernel begins its boot sequence, where the essence of its work is to abstract the underlying hardware from the software and provide an environment in which application software can run. Once this
ICARCV 2006
only the superuser to execute the program (i.e. UID == 0), as a further measure, a process file was kept in the operating system’s run-time variable directory (i.e. /var/run) to keep track of program executions. Starting X
Fig. 1.
The Login Systems Architecture
procedure has completed the kernel creates a new process of control and invokes the login system to take control of the operating system. The implemented login system then waits for a valid user to present their biometric data. Once the user has been authenticated, the login system sets up the user’s X11windowing environment and waits for the user to log out, at which point control of the operating system is passed back to the implemented login system and the process is repeated. The authentication manager implemented in the developed login system is made up of the components shown in Figure 2, where all components, except the video device, were designed and implemented from scratch. The authentication manager controller is the authentication managers main thread of execution and is responsible for issuing the tasks between the various components that make up the authentication manager. The implementation methodology outlined in this paper is specific to the current facial recognition system, however during all stages of development emphasis was placed on easy configuration of the system for various other biometric techniques, once the relevant drivers become available.
A new system thread is created in which a local X server was initialised and started. Providing a windowing system for the graphical user interface. The X authorisation cookies (tell the operating system who is privileged to currently use the X11 server) were set with high restrictions. Building Classification Structures The facial recognition component is notified to build the classification structures used for authenticating the captured images. The controller also notifies the facial recognition component of which images are to be used for training, these images are obtained from the biometric data storage component. Opening Camera Device The video device component is notified to configure itself and prepare to start capturing frames, from the video device (/dev/video). Initializing GUI The GUI component is notified to initialize its environment and get ready to start drawing the captured frames to the screen. Initializing Events The authentication manager controller passes control amongst the other components by triggering system events (typically timeout events). These events are created, initialized and appropriately configured.
Fig. 2.
Developed Components of the Authentication Manager
Prior to passing control amongst various other developed components of the authentication manager, the authenticationmanager controller implements a number of critical initialization tasks. These initialization tasks include: Access Security Due to potential consequences of mischievous use of the login system, tight access control restrictions were placed on the execution of the program. This was achieved by allowing
Once initialized, the authentication-manager controller needs to handle the events used to control its execution flow. Handling of events is achieved through the implementation of a looping function, which listens for events to occur (i.e. new image has been captured) and handles the event by calling the appropriate function. Algorithm 1 shows the main events implemented in the authentication-manager controller, and how these events are dispatched. The algorithm describes an abstract view of the control-flow and interaction between the various components that make up the implemented authentication manager. Once the system has established a users identity it then passes control of the system to the session manager. The session manager implemented in the login system provides the functionality necessary to allow the authenticated
Algorithm 1 controller main loop 1: loop 2: if capture image event occurs then 3: signal video device component to grab current video frame. 4: end if if new RGB image captured event occurs then 5: 6: signal GUI component to draw image to screen. 7: signal image pre-processing component to convert captured image. 8: end if 9: if new 255 grey image event occurs then 10: signal facial recognition component to identify image. 11: end if if biometrc data matched event occurs then 12: 13: signal video device component to terminate. 14: signal GUI component to terminate. 15: signal facial recognition component to terminate. 16: close down authentication manager and pass system control to the session manager. 17: end if 18: if login process timed out event occurs then 19: signal video device component to terminate. 20: signal GUI component to terminate. 21: signal facial recognition component to terminate. 22: notify the user that login attempt failed. 23: restart authentication manager and await a new login attempt. 24: end if 25: end loop user access to the system’s resources. Once called, the session manager creates a new control process with access restricted according to the user’s privileges on the system. This newly created process is configured according to the users preferences with numerous environment variables being set as well. At this point, the session manager makes system calls to numerous system scripts to ensure the compliance with current Linux security requirements and to keep security logs consistent through all login mechanisms. The system devices (i.e. all files in /dev) and various other system resources must be temporarily assigned over to the user so they can be accessed. Mechanisms for providing and removing user access to system devices is also implemented into the session manager. Once the operating system has been configured appropriately for the user, the final task of starting the user’s windowing session begins. To achieve this, the implemented session manager first authenticates the user with the systems X11 server by setting appropriate user information into the encrypted X11 authentication cookie (the authentication mechanism used by X11 servers). Finally, a new process is created and a system call to execute the users desktop environment, e.g. GNOME or KDE, is signalled. At this stage the user is successfully logged into the system.
The implemented session manager awaits a signal from the desktop environment that the user wishes to log out. On this request, the session manager removes all access rights assigned to the user and passes control back to the authentication manager. III. E XPERIMENTS , R ESULTS AND A NALYSIS A. Data Sets The images used to train the system were carefully selected from a self obtained database of facial images. Selection criteria of the training facial images included: ensuring all images were frontal views of the face, only small deviations between facial expressions, and limited background noise in the images. After elimination 11 suitable candidates were used in the database. For each of the candidates, 4 of their images were selected to be used for training, thereby resulting in a training data set of 44 facial images. Each of the suitable candidates images were selected, such that, they would best describe the appearance of that user over different days. Images which were not frontal-view oriented or contained excessive facial expressions were excluded as the main objectives of the experiments was to test the facial recognition technique’s ability to authenticate users for a login system, and not to test the technique’s robustness with altering facial expressions or orientation. The data sets used to test the system’s ability to correctly authenticate users included different samples from each of the 11 users previously discussed. These images were used to test the system’s ability to correctly identify individuals of which the system knew, i.e. the individuals used in training the system. Additional data sets were obtained for analyzing the system’s ability to reject users not known to the system. Data samples from 4 additional individuals were obtained and subject to the same selection criteria. Due to the limited number of testing subjects available, a larger facial database was obtained from the Olivetti Research Laboratory (ORL) [2]. These images were scaled so the subjects’ facial images were of the same scaling as those obtained through the system’s training procedures. The resulting database contained 400 images from a number of subjects, where the facial images varied in lighting conditions, facial expressions, facial details, and slight deviations about the frontal positions. Database Known users Unknown users ORL
No. People 11 4 40
Images/Person 10 10 10
Total 110 40 400
TABLE I T ESTING DATA S ETS
B. Eigenfaces Preliminary investigations identified Eigenfaces as the most suitable candidate for providing facial recognition within the login system’s environment. However, as stated in the
preliminary investigations, new research has shown DCT to outperform Eigenfaces within environments similar to that of the login system. However, as this research is new, insufficient data existed to select the most appropriate algorithm. Therefore, additional experimentation was undertaken to ensure the appropriate algorithm was selected. For the evaluation between DCT and Eigenfaces, experiments were conducted using the data samples from the known users database. Only system generated data sets were used to ensure consistency between the simulated tests and its eventual porting to the system. [5] identified DCT as outperforming Eigenfaces when applied to the Yale face database [9]. To analyse if these outcomes could be repeated using our system, these experiments were repeated with the system generated facial images. The Eigenfaces [6] was chosen for the face recognition algorithm. This approach is one of the preferred techniques in face recognition due to its simplicity, ability to perform in real-time situations and robustness under varying illuminations. Preliminary investigation was conducted on the Energy Histogram as the alternative face recognition algorithm. In [5], the Energy Histogram was reported to outperform Eigenfaces when applied to the Yale face database [9]. To analyze if these outcomes could be repeated using our system, these experiments were repeated with the system generated facial images. The results showed that Eigenfaces performed significantly better than the Energy Histogram when tested on the system generated database. Although this experiment contradicts the results of [5] from experiments on the Yale database, investigations into the results suggested this was a result of larger variations in the histograms of the system generated database. Analysis into the data resulting from the experiments on DCT and Eigenfaces resulted in DCT performing best with the number of histogram bins set at 40 and Eigenfaces performing best with the threshold set to 6800. The best results yielded from each of the algorithms is presented in Table II. Algorithm DCT Eigenfaces
Precision 75% 97%
Recall 97% 97%
TABLE II P ERFORMANCE C OMPARISON BETWEEN DCT AND E IGENFACES
Further statistical analysis of the results further showed that Eigenfaces performed significantly better than DCT when tested on the system generated database. Although this experiment contradicts the results of [5] from experiments on the Yale database, investigations into the results suggested this was a result of larger variations in the histograms of the system generated database. Slight changes in the intensity of the images affected the DCT approach more than that of the Eigenface approach, probably resulting from the DCT taking each pixel as a contribution to the feature set.
C. Recognition Experiments (Without Login ID) To evaluate the system’s ability to recognise a user, experiments were conducted to validate the system’s ability to correctly authenticate users through facial recognition and to reject users not known to the system. The system was trained using all images from the training set previously described. Hence, authentication of users was completely automated and required no user input. For testing, all three databases described in Table I were used for evaluating the system. Experiments for determining the system’s recognition capabilities included the analysis of the system’s classification abilities on the known users and unknown users databases. The results from these experiments are presented in Figure 3 and show the recognition system’s precision and recall statistics over increasing thresholds. By observing the graph’s trend in Figure 3 across the threshold range, a threshold of 6000 is optimal as the metrics are balanced (i.e. graphs intersect) and precision are recall both yield perfect statistics (100%).
Fig. 3.
Recognition Results Over Increasing Thresholds
D. Verification Experiments (With Login ID) To evaluate the system’s ability to verify a user, an experiment was conducted for each of the 11 users known to the system. For each of these experiments, the system was trained with 4 images from the training set of the user to be verified. Authentication of users requires the user to first provide their username to the system, so that the authentication system can obtain the appropriate user’s images from the database which the user is verified against. The remaining 10 images for the user being identified, were used for testing the system’s ability to correctly authenticate. To validate the system’s ability to reject unknown users from accessing the system, the remaining 10 users’ data sets from the known users database, along with the 4 users’ data sets from the unknown users database (see table I) were used in each of the experiments. Experiments for determining the system’s verification capabilities included the analysis of the classification abilities on the known users and unknown users databases. The results from these experiments are presented in Figure 4 and show the averaged precision and recall statistics over increasing
thresholds. The results were averaged since each of the user’s experiments were conducted independently over the threshold range. By observing the graph’s trend across the threshold range, a threshold of 5000 was selected as the most appropriate value as the precision is 100% and recall is 97%.
Fig. 4.
Averaged Verification Results Over Increasing Thresholds
IV. C ONCLUSIONS This research developed a complete prototype login system for Linux that provided authentication services through biometric techniques. Considerable research was required to identify how biometrics could be integrated into an application capable of providing authentication services, and how this application was to be deployed into the Linux operating system. Preliminary investigations identified a suitable biometric technique for which authentication could be achieved. Due to the limited hardware support currently available for Linux, facial recognition was the only suitable biometric technique for which hardware supported was identified. Analysis into alternative facial recognition algorithms identified the Eigenface approach as the most suitable candidate for providing user authentication in the login system, primarily as it was able to handle the system’s environment (in which images were captured) and requirements better than the other algorithms. The software required to implement the login system components was developed as reusable modules for allowing the plugging in of various biometric algorithms to perform user authentication. User enrolment software was also implemented to obtain training samples from the user. Evaluation into the efficacy of using the Eigenfaces algorithm to provide user authentication was also presented and discussed. The developed login system is complete and functional within a Linux environment and currently implements Eigenfaces facial recognition for user authentication with promising results. Current results suggest the login system is perfect with both precision and recall rates of 100%. However, the precision and recall rates are unlikely to always be 100%, especially as the number of users enrolled in the system grows. R EFERENCES [1] Iridian. Iridian iris technologies, 2003. Retrieved: http://www.iriscan.com [January 2003].
[2] ORL. The ORL database of faces. AT&T Laboratories Cambridge Website, 2002. Retrieved: http://www.uk.research.att.com/facedatabase.html [January 2003]. [3] PUPPY. Puppy suite for Mac OS X. Online, 2002. Retrieved: http://puppysuite.pspinc.com [January 2003]. [4] A. Reeder. Biometrics and Linux. In Linux Australia Conference, Perth, Australian, 2003. [5] R. Tjahyadi, W. Liu, and S. Venkatesh. Application of the dct energy histogram for face recognition. 2nd International Conference on Information Technology and Applications, 2004. http://charybdis.mit.csu.edu.au/icita/2004/abstracts/70-5.htm. [6] M. Turk and A. Pentland. Eigenfaces for recognition. Journal of Cognitive Neuroscience, 3(1):71–86, 1991. [7] D. Verton. Network access made simple, secure. Federal Computer Week, Apr. 2000. Retrieved: http://www.fcw.com [November 2002]. [8] Viisage Technology. Advanced biometric identification systems. Viisage Technology Website, 2003. Retrieved: http://www.viisage.com [March 2003]. [9] Yale. Yale face database. Yale University Website, 1997. Retrieved: http://cvc.yale.edu/projects/yalefaces [December 2002].
