Explore Technology Certificate Programs That Fit Your Needs /// Click here to learn more.
Welcome Guest | Sign In
TechNewsWorld.com

Safeguarding the Keys to the Linux Kingdom

Safeguarding the Keys to the Linux Kingdom

Without proper controls, anyone with access to the root account -- the virtual "keys to the kingdom" -- is given complete super-user privileges without justification based on their job classification, specific duties or role within the IT department. This violates the security best-practices doctrine of least privilege, and can expose proprietary systems and information to malicious activity and sabotage.

By Ellen Libenson LinuxInsider ECT News Network
03/01/07 4:00 AM PT

One of the most common security challenges Linux and Unix IT administrators face is how to effectively manage the root or super-user account. In an age of regulatory compliance and data privacy laws -- and as more and more organizations elect to run mission-critical financial, CRM (customer relationship management), SCM (supply chain management) and other applications in heterogeneous Unix and Linux environments -- controlling and auditing privileged account access is more crucial than ever.

Without proper controls, anyone with access to the root account -- the virtual "keys to the kingdom" -- is given complete super-user privileges without justification based on their job classification, specific duties or role within the IT department.

This violates the security best-practices doctrine of least privilege, and can expose proprietary systems and information to malicious activity and sabotage that could result in catastrophic information leakage or mistakes that could bring down an entire company (let alone its network).

Be Cautious of Insiders

For some, the idea of carefully controlling elevated privileges within Linux or Unix environments may seem counterintuitive or even draconian because of the perceived distrust of administrators that it implies. While most IT staffers can and should be trusted with this level of access, consider that study after study reveals that insiders are often at the center of security breaches and incidents of data theft.

According to a recent Computer Security Institute study that was conducted jointly with the FBI, 80 percent of surveyed respondents reported security incidents involving insider abuse of privileges -- this is up from 64 percent during the previous year. What's more, a 2005 IDC Research survey found that 31 percent of responding organizations had terminated employees or contractors because of internal security violations.

Need further evidence? A recent poll conducted by the online publication Dark Reading asked 648 IT pros -- the individuals who are often entrusted with the "keys to the kingdom" -- if they ever accessed proprietary information during their careers. More than one-third -- 37.5 percent to be exact -- admitted to abusing their security privileges and accessing information in company files. Ten percent of respondents admitted to accessing unauthorized information on a regular basis.

Despite these findings, many IT managers still do not fully understand the implications of unmonitored super-user accounts and do not see the problem with multiple administrators having more privileges than needed or sharing account access. In determining who should have access to critical systems and data, it is important to help IT managers and staff understand that IT must have systems and policies in place that create an enterprise-wide security environment based on role and scope.

Sudo or Don't?

After making the decision to implement controls to protect the root account, organizations face the challenging matter of how exactly to accomplish this. Because most IT administrators are trustworthy, organizations must properly manage access rights without completely hampering the IT staff. One of the fundamental questions that must be thoroughly addressed is whether to deploy commercial solutions or rely on freeware.

Perhaps the most widely used open source program for delegating responsibilities within Linux and Unix environments is sudo (superuser do). The basic intention of sudo is to provide administrators with a way to allow users to access certain programs that require the root password without giving them complete root privileges. Many IT departments feel it is OK to use suid (also known as setuid, which is short for set user ID) or sgid (set group ID) to delegate administrative access because it is easy to set an executable as the suid root and it will likely work "just well enough."

While sudo does contain a handful of positive attributes, IT mangers familiar with the program understand that its drawbacks make it an incomplete, insufficient solution.

It is a "quick and dirty" approach that invariably grants more privileges than are required to do the job, resulting in an unnecessarily high risk of accident or attack. Some tasks still do require root privilege, and hackers are crafty enough to exploit this by looking for ways to subvert suid root processes while still retaining root's context.

In addition, in a smaller environment -- for example, 10 or 20 servers -- sudo may be able to handle a business' access control needs. However, larger organizations often have hundreds of servers running dozens of different versions of Linux and Unix operating systems. The larger and more complex an organization is, the greater the number of administrators who need to be granted access and who require privileged access, thus increasing the likelihood of mistakes and deliberate attacks. Sudo is not practical nor does it scale well in very large heterogeneous deployments.

Undiscovered Vulnerabilities

Another drawback associated with relying on open source solutions is that vulnerabilities often go undiscovered and unreported. Users must rely on open forums for solutions to noted problems -- if and when they are found.

For instance, running most scripting languages from sudo is generally considered not to be safe given it was discovered that running a Python script through sudo could enable one to gain root access.

With sudo continuing to fall out of favor with administrators at large-scale IT environments, organizations are turning to commercial identity and access management solutions as more effective means of addressing insider threat to satisfy compliance regulations and follow best security practices without alienating the IT department.

Turning to IAM

Identity and access management (IAM) refers to a comprehensive set of solutions used to identify users within an organization and control their access to systems and information by aligning their designated user rights, identity and role to the correct intellectual property and digital assets. The super-user accounts often present within Linux systems include the ability to create additional accounts, modify system data or perform application and database functions outside the control of the application system for which the account was issued.

Because privileged accounts carry elevated capabilities, they must be more closely monitored for misuse. Deploying commercial IAM solutions accomplishes this far more effectively than sudo or other freeware applications.

In most Linux environments, users, administrators, developers and testers require access to critical applications and data hosted on a system. In larger organizations, multiple administrators will have varying responsibilities for each machine, requiring multiple people to have super-user access.

To manually set up these kinds of varying levels of responsibilities using sudo is a painstaking task, and native Unix and Linux systems offer little or no means to control access. What's more, sudo lacks the ability to granularly track, log and record activities conducted by administrators using super-user credentials.

Even when native systems are combined with account management subsystems -- including Network Information Service (Sun Microsystems' client-server protocol for keeping track of user and host names on a network) or Lightweight Directory Application Protocol (LDAP) -- they simply cannot meet the compliance requirements mandated by SOX Section 404 and other regulations.

These subsystems do not provide the level of granular access control to systems and commands needed, and they do not create detailed audit logs to track user activities or control access on a user-by-user or machine-by-machine basis. When the root or super-user password for a particular server is widely known, every user could conceivably have access to that machine, exposing sensitive data to users who have no authority to view or modify it.

Benefits of IAM

Organizations can benefit greatly from an IAM system that ensures only authorized users are able to access proprietary systems and information. An effective IAM solution will also ensure that those authorized to perform various duties with elevated privileges and access will be confined to what their role designates.

Their activities will be recorded and an indelible audit trail will be created. In addition to helping guarantee the integrity of data in financial systems, this is invaluable for forensics and troubleshooting purposes, and it often serves as a deterrent to malicious or unethical behavior. Role-based access can and should be granularly defined to meet compliance and data privacy requirements.

If an organization works within the framework of these best-practices approaches, an IAM solution will allow for an easier implementation and enforcement of security policy related to privileged accounts.

These technologies serve as a centrally controlled application for password management for the hundreds -- or even thousands -- of systems typically running within a Windows/Unix/Linux network. By making it easier to authenticate users and automate access restriction, organizations will be one step closer to a secure infrastructure and to complying with industry and federal regulations.


Ellen Libenson is vice president of product management for Symark Software. E-mail her at elibenson@symark.com.


Facebook Twitter LinkedIn Google+ RSS