/Pam-2man-Auth

Two person authentication module for PAM

Primary LanguageCOtherNOASSERTION

Two Man (2 Person) Authentication for PAM (Pluggable Authentication Module).

I. Background
=============
Our focus on the ongoing, ever-changing threats and attacks from outside our i
networks should not distract us from protecting against threats from 
within—especially the low-likelihood, but high-consequence, insider threat 
posed by privileged, trusted users. The recent National Security Agency (NSA) 
information leak incidents have prompted immediate focus on the topic of 
internal security. In these events, an employee with privileged access disclosed 
confidential data to the public without permission, prompting government and 
non-government organizations to review their internal security controls and 
reassess their effectiveness in protecting against insider threats.

Despite the risk of insider attacks, most security products do not offer 
protection against these attacks. Moreover, identifying the source of internal 
adversarial activities is a challenging task. How can an organization protect 
confidential information from malicious insider attacks? In response to 
questions posed by reporters from several news outlets, the director of the NSA,
K. Alexander, announced that a “ two-man rule” would be instituted on NSA 
systems to prevent a recurrence of similar events. The announcement triggered 
questions about the feasibility and effectiveness of implementing a two-man 
rule.

This research and development study aims to answer those two questions: 

1)	Is a two-man rule feasible in a production environment? 

2)	How can a two-man rule be enforced?

We discuss the development and implementation of an enforceable two-man rule 
for authenticating privileged users, using a Pluggable Authentication Module 
(PAM) plugin, in a Linux environment, demonstrating the feasibility and 
effectiveness of requiring joint agreement between two trusted users before 
gaining access privileged actions.

II.Defining Two-man Rule
========================
Two-man rule (also known as two-person rule, two-man authentication, or 
two-person authentication) is a security control that prohibits independent, 
single-person access to critical data, applications, and computer systems.  The 
rule requires two authorized individuals who are in constant view of each other 
to concurrently login to the system before access can be granted. This approach 
ensures that accidental or intentional malicious activities cannot be performed 
without the consent of the second person. A literature search returned no 
examples of designs or implementations of two-man authentication. The work 
presented in this paper bridges the gap between concept and implementation by 
demonstrating the feasibility and effectiveness of an enforceable two-man rule 
in Linux-based systems.

III.Two-man Authentication Proof-of-concept
===========================================
This proof-of-concept demonstration addresses the idea of requiring a second set
of credentials to access confidential data and/or change critical configurations
on secure systems. To accomplish this, we developed a plugin using the PAM 
system, the system used for user authentication and security on Linux systems. 
PAM can authenticate users in a variety of ways, but most typically it uses 
passwords.

PAM allows applications to employ different user-authentication methods using a 
stacked plugin architecture. This means that plugins, such as the two-man 
authentication plugin developed in this study, do not require knowledge of the 
underlying authentication type of a specific application. In other words, such a
plugin could be used with password authentication as easily as with biometric 
authentication, as long as the other components of the PAM stack and the 
application itself supports a given plugin.

For our proof of concept, the plugin was added to a Linux system for use with 
sudo. Sudo is a console program used to assume temporary administrative 
privileges that are required to execute a program, access or modify a file, or 
for other specific functions. We used sudo in our proof of concept because it is
the most commonly used method for obtaining elevated privileges to execute 
commands in a Unix/Linux environment, making it ideal for enforcing two-man 
authentication.

Sudo, by default, uses PAM as its method for authenticating a user’s system 
access credentials and then uses its own internal method to evaluate whether or 
not a user is allowed elevated privileges for the given command. However, a PAM 
plugin cannot decide whether to permit the sudo-user to perform actions; the 
permission-to-execute decision must be performed separately. To decide whether 
to grant permission, our implementation used a secondary authentication method 
for our second user, namely, a system “group.”  This secondary “group” provides 
additional security because it enforces a hierarchy of permissions.


This implemented design permits both granular control over execution permissions
and hierarchical, supervisory control to ensure management (authorizer) 
oversight of the activities performed by the administrator. This fine-grained 
(per system function) and oversight control is defined by group memberships. 
Specific authorization to perform functions is granted via sudo's internal 
authentication scheme. Managerial authorization is granted through the 
“sudo-authorizer” group membership. A person could be in the administrator 
group, the authorization group, or both. Membership in one group does not imply 
or grant membership in the other group:

1)	A managing administrator can have authorization to perform functions (sudoer) and authorize others to perform actions (sudo-authorizer); 

2)	A security manager can have no authorization to perform actions (non sudoer) but have permission to authorize administrative actions (sudo-authorizer); and 

3)	A system administrator can perform functions (sudoer) but not authorize others to perform actions (non sudo-authorizer).

IV.Discussion and Conclusion
============================
The two-man authentication plugin developed was designed for use with sudo, a 
primary Linux/Unix-based tool for granting permission to privileged operations. 
Permission to use other programs could also be controlled using the plugin.

This proof-of-concept demonstration was successful: two non-root user logins and
corresponding passwords were required before permission to execute was granted. 
The requirement for not allowing root users prevents a single user from 
subverting the check for the second authorizing user.  The plugin was also 
successfully tested using PAM’s fingerprint authentication module for 
password-less biometric authentication.

Additional security is obtained by creating a supervisory role for the second 
person, who not only witnesses, but also authorizes, the actions of the primary 
person (e.g., the system administrator). This limits the opportunity for 
collusion between two regular administrators and requires that any administrator 
obtain the permission of a supervisor, who authorizes and witnesses their 
actions.

References
==========

[1]Gellman, B.; A. Blake; G. Miller. 2013. “Edward Snowden comes forward as source of NSA leaks.” The Washington Post [modified 2013; cited July 31, 2013]. Available from: http://www.washingtonpost.com/

politics/intelligence-leaders-push-back-on-leakers-media/2013

/06/09/fff80160-d122-11e2-a73e-826d299ff459_story.html.

[2]Ragan, S. “Preventing a Snowden-Style Security Breach.” 2013. Slashdot [modified 2013; cited August 20, 2013]. Available from: http://slashdot.org/topic/bi/preventing-a-snowden-style-security-breach. 

[3]Drew, C.; S. Sengupta. 2013. “N.S.A. Leak Puts Focus on System Administrators.” The New York Times [modified 2013; cited August 20, 2013]. Available from: http://www.nytimes.com/2013/06/24/

technology/nsa-leak-puts-focus-on-system-administrators.html?

pagewanted=all&_r=1&.

[4]Brower, H.H.; S.W. Lester; M.A. Korsgaard; B.R. Dineen. 2009. “A Closer Look at Trust between Managers and Subordinates: Understanding the Effects of Both Trusting and Being Trusted on Subordinate Outcome.” Journal of Management. March 1, 2009; 35(2):327–347.

[5]Lackey, E.D. “Using Pluggable Authentication Modules (PAM).” Red Hat Enterprise Linux 6. Raleigh: Red Hat; 2011.