Zero-trust is an approach to architecture that does not (or should not) stop at the edge of the data center. Extending zero-trust principles all the way down to managing Linux permissions ensures least-privilege access and protects against a variety of risks that arise from attackers impersonating privileged users or insiders performing unauthorized access. The SGNL platform extends zero-trust principles to access to Linux through Pluggable Authentication Modules.
What Are Pluggable Authentication Modules
Pluggable authentication modules (PAM) are PAM API implementations allowing developers to perform custom authentication processes in the Linux operating system. Since its inception, PAM modules traditionally have extended default authentication mechanisms, but this post highlights the method and benefits of augmenting the authentication process. Since you can require different pluggable authentication modules for a specific operating system service (e.g., ssh, sudo), you can implement a PAM module that calls an external authorization service to augment the authentication decision made by any local operating system configuration.
For example, a user may establish an ssh session with a Linux server only during business hours, the network location matches a specific region, and an active service desk case is open for the user. This temporary access does not rely on “long-standing” or ambient permissions for the user but rather the PAM module allows or denies access to the server or command being executed based on dynamic authorization decisions made by an external policy decision point with critical business context.
Continuous Access Management
Continuous access management is the combination of methods, technologies, and business processes used to manage access to applications, infrastructure, or data using a dynamic and real-time authorization check for every request made by a user, device, or application to a resource provider (e.g., Application, Microservice, Database).
Continuous Access Management for Linux
Continuous access management, which includes dynamic, fine-grained authorization, must be considered as a part of an overall zero trust security strategy for accessing critical infrastructure. Here are some reasons why extending PAM modules with continuous access management makes sense:
Server access should be more than authentication - Historically, PAM modules are used to authenticate a user, but there is one specific PAM API function (pam_sm_acct_mgmt) that is not meant to identify who the user is, but rather answer the question of whether the user should be able to access the server or run a command in that very instant the user is attempting to access the server or run a command (e.g. sudo). This ability to implement the account management interface of the PAM API has been included since the beginning of the API implementation. See this post from the beginning of PAM modules in 1997 for more information.
Privilege escalation requires business justification - In most cases today, it is not sufficient to just allow escalation of privileges on a server by adding the user directly to the sudoers file or an admin group. In addition, sharing user accounts (e.g system privileged account) opens an organization to significant risk and challenges in auditing who (i.e. person) is behind the usage of the shared account.
Most security administrators and program managers will require business rules and or justification for access. For example, if a certain set of Linux servers are used to host a sensitive application and sensitive data, then it may be necessary to ensure there is an approved service ticket that necessitates access to the Linux server. The only way to implement this easily is by using an external authorization policy engine, like SGNL, that has the capability of recognizing organization state and context.
Adopt a least privilege strategy for your servers - It is common to see audit findings that demonstrate over-provisioned administrative users or users with permissions accumulated over time on Linux servers (ie - promotion, team transfer, etc.). Admin group membership is commonly used to allow sudo, but the burden of managing these groups on all servers tends to result in users’ accumulated ambient access and introduces unwanted organizational risk and complexity.
Scale consistent authorization policy across the infrastructure - Dramatically reduce administrative group maintenance burden and increase auditability of server access by centralizing policy and producing consistent access decisions across all your servers. Let’s expand on each of the three benefits highlighted here:
- Ease of administration - In some cases, sudo privileges are managed locally on a per server basis. This makes it difficult and time consuming to update local policies. Instead, continuous access management centralizes administration so that one policy can be easily applied across all infrastructure components.
- Consistent decisions - With access policy is centralized, and only one policy exists; you can ensure that access evaluation results will remain consistent across the infrastructure.
- Auditability - Since all access decisions are made centrally by a single, external policy engine, they are at the same time generating access, audit and telemetry data. This data may be stored and reported on for audit purposes.
Augment your risk mitigation strategy - Most organizations use audit frameworks for proving their security controls are in place and are operational. It is common to gather evidence of a process, run a report, or validate technology components for proving a security requirement is covered by a security control. In some cases, companies refer to existing control catalogs such as the NIST control catalog. One control regarding executing privileged actions states, “Prevent non-privileged users from executing privileged functions.” This is control AC-6(10) in the NIST SP 800-53 Revision 5 controls catalog. With this PAM module approach you can prevent non-privileged users from executing privileged commands such as sudo without business justification as specified by organizational policy. This approach gives the security administrator ease of centrally managing access policy, consistent authorization decisions, and auditability for fulfilling audit controls such as the one highlighted here.
Using SGNL For Linux Servers
SGNL provides continuous access management by continuously ingesting business context from systems of record. With SGNL, access control is enforced consistently and easily across all protected services, infrastructure, applications, and data using easily-readable policies. By using SGNL for Linux PAM modules, you can externalize Linux infrastructure access management to a scalable and modern platform, minimize security exposure with context-based run-time access decisions, and implement a truly least-privileged approach to securing your Linux environment.
- Business Data Driven Continuous Access Management - Any changes recorded in an organization’s business systems (e.g. ServiceNow, Salesforce, HRIS) of record are automatically and rapidly reflected in the PAM module access decisions without changing local Linux configuration.
- Real-time Audit and Comprehensive Reporting - With SGNL, all PAM module access decisions are logged centrally with the policies that contributed to the decision to grant or deny access.
- Centralized Human-Readable Policies - Human-readable policies using reusable snippets enable organizations to scale policies without losing manageability and consistency. SGNL allows you to create reusable snippets, and reuse them in multiple authorization policies. This allows for easier maintenance, time savings, and broader coverage for an authorization policy.
- Consistent Authorization Decisions Across PAM enabled Linux services - PAM enabled Linux services using SGNL, provide the same access decisions consistently because they are based on the centrally managed policies.
- Contextual Authorization Decisions - Any access decision is determined considering the context of the request coming from the PAM module at runtime. The request context received from the PAM module is kept intact through the SGNL access service and back to the PAM module.
With SGNL, you can externalize access management of your Linux servers, to provide consistent, fine-grained decisions that are based on human readable policies, which refer to the dynamic data in your systems of record.
Solution Approach
The solution consists of an SGNL policy engine (integration via the access service API), graph directory, data ingestion adapters, and human-readable policy used for making authorization decisions. A PAM module is configured to send authorization requests to the SGNL access service via the SGNL REST API. The SGNL access service responds to the PAM module with allow or deny decisions considering the context of the authorization request. For example, context may consist of principal data, command being executed (e.g. ssh, sudo), and network IP address. If the request is denied, the PAM module does not permit the command to execute.
Logical Diagram Of Solution
How Does SGNL Work
SGNL continuously ingests data from systems of record to a central graph directory via resilient and performant data ingest adapters. This data includes identity data, such as users and groups, and any relevant data required to define access policies, such as CMDB, ITSM cases, tickets from JIRA, or customers from a CRM.
In this post, we use ServiceNow and Azure Active Directory as the Systems of Record. Azure AD is our Identity Provider system of record, and ServiceNow provides the assigned and active case for the user. This case justifies the user’s ability to elevate their privileges using the sudo command.
Once the system of record data sources are set up, SGNL administrators can quickly author and manage human-readable policies based on the ingested data for granting or denying access to applications, APIs, servers, and sensitive data. By implementing a centralized approach, SGNL provides consistency in centralized policy management, audit logging, and reporting across all assets an organization desires to protect.
Instead of simply basing privileged access to servers on a simple authentication scheme, you use SGNL to graphically build a human-readable policy that ensures that every protected command (e.g. ssh, sudo) on the protected Linux server is evaluated against the latest data ingested from systems of record and the policies defined in SGNL.
An example of a real human-readable policy for managing sudo access
This policy checks if the principal is a valid SRE team member and has an assigned ServiceNow case. SGNL applies this policy to an incoming access request from the PAM module. The PAM module sends the logged in user and the command (e.g. sudo) they want to execute. SGNL will return an “Allow” decision if the employee is a valid SRE team member and has an assigned case or a “Deny” decision if either of those conditions fail to match.
Sample Request Flow
A Linux administrator may simplify authorization policy for accessing Linux infrastructure by delegating complex authorization logic to the SGNL policy engine. The authorization decisions are made by the SGNL policy engine which is calculating policy against continuously ingested data from various systems of record (e.g. Azure AD, ServiceNow). In addition, SGNL automatically creates the appropriate relationships for that ingested data, and it calculates multiple human-readable policies in milliseconds. Below is an example sequence diagram for a user in the Linux shell running the sudo command, and having that be authorized by the SGNL policy engine.
- A principal (e.g. user) runs the sudo command on a Linux server.
- The configured PAM module gathers request context information (e.g. Linux username), IP Address, action (e.g. sudo) and sends an authorization query request to the SGNL access service API.
- The SGNL policy engine calculates the human-readable policies associated with the authorization request in milliseconds and determines a final decision (allow/deny) to the PAM module. There is no extra configuration or modification for the policy engine for benefiting from the performant policy calculations and response.
- (A) If the decision made by the access service is allowed, the access service responds with an allow response. (B) If the decision is denied, the access service responds with a denied response.
- (A) If the PAM module receives an allow decision, it then allows the command (e.g. sudo) to execute. (B) If the PAM module received an denied decision, it then denies the execution of the command (e.g. sudo).
PAM Module Sample Code
In the following PAM module C code snippet, you see the simple implementation of the PAM API pam_sm_acct_mgmt function. If the PAM configuration requires the PAM module as part of executing a command such as sudo or ssh, the Linux operating system sends the PAM handle to the PAM module for execution of the authorization logic. This function, calls a callSGNL() function which calls the SGNL policy engine for policy evaluation and decision response.
Based on the example policy in this post, the SGNL API either returns an allow if the user can run the command (e.g. sudo, ssh) or deny if the user does not meet the policy conditions. The PAM module processes the response appropriately - allow the access to execute the command (e.g. sudo), or log and deny the command execution.
You can download the full example from the SGNL examples repository.
Code snippet from PAM module
/_ Expected hook by the PAM implementation. This is where the call to SGNL happens. _/
PAM*EXTERN int pam_sm_acct_mgmt(pam_handle_t \_pamh, int flags, int argc, const char \*\*argv) {
const char* username;
const char* host = NULL;
const char* service = NULL;
int res = 0;
/* Read SGNL configuration file. */
read_config();
(void) pam_get_item(pamh, PAM_SERVICE,(const void **) &service);
(void) pam_get_item(pamh, PAM_RHOST, (const void **) &host);
(void) pam_get_user(pamh, &username, "Username: ");
/_ Log some info to the PAM syslog _/
pam_syslog(pamh, LOG_INFO, "SGNL PAM Module: username [%s]", username);
pam_syslog(pamh, LOG_INFO, "SGNL PAM Module: Host: %s",host);
pam_syslog(pamh, LOG_INFO, "SGNL PAM Module: Linux service: %s",service);
/* Call SGNL for authorization. See the full implementation in the examples Git repo */
res = callSGNL(username,service);
if(res != 1 || 0 ){
/* Oh no! something bad happend. Log error and return an error to the PAM handle.*/
pam_syslog(pamh, LOG_INFO, "SGNL PAM Module: Received error from SGNL API %i",res);
pam_syslog(pamh, LOG_INFO, "SGNL PAM Module: Please check configuration in the sgnl_pam.json file in /etc/sgnl.");
return PAM_PERM_DENIED;
}
else {
pam_syslog(pamh, LOG_INFO, "Called SGNL: %i", res);
/* Send an allow or deny to the PAM handle. */
if (res == 1){
/* Allow access */
return PAM_SUCCESS;
} else if (res == 0){
/* Deny access */
return PAM_PERM_DENIED;
}
}
/* Deny by default if we did not receive a decision from SGNL. */
return PAM_PERM_DENIED;
}
Configuration
The PAM module is straightforward to configure. Below is an example of the sudo PAM configuration line in the sudo file in the /etc/pam.d directory.
account required sgnl_pam.so
This configuration instructs the operating system to load the PAM module for calling the SGNL policy engine and evaluate the access policy for running the sudo command.
For steps to build, install, and configure the PAM module visit the Git repo’s readme file. For steps for configuring the protected Linux infrastructure in the SGNL user interface visit the protecting Linux systems with SGNL help article.
Conclusion
Using SGNL for managing access to Linux servers, especially servers that host high-risk applications and data - organizations can reduce risk by limiting access without business justification, security administrators can minimize authorization logic complexity, and teams can centralize access management policy in a single platform for making complex, consistent, and continuous authorization decisions.
Schedule time with a SGNLer to see how all this can work in your context.