Root Account

Almost every Unix system comes with a special user in the /etc/passwd file with a UID of 0. This user is known as the superuser and is normally given the username root. The password for the root  account is usually called simply the "root  password."

The root  account is the identity used by the operating system itself to accomplish its basic functions, such as logging users in and out of the system, recording accounting information, and managing input/output devices. For this reason, the superuser exerts nearly complete control over the operating system: nearly all security restrictions are bypassed for any program that is run by the root  user, and most of the checks and warnings are turned off.

On Solaris it is possible to restrict root's capabilities via RBAC. In such cases even if the superuser account is compromised, some kinds of damage are not possible. Trusted Solaris has additional features and allows  not to have a superuser at all.

The root account has virtually unlimited access to all programs, files, and resources on a system. The root account is the special user in the /etc/passwd file with the userid (UID) of 0  and is commonly given the user name, root.

It is not the user name that makes the root account so special, but the UID value of 0. This means that any user that has a UID of 0  also has the same privileges as the root user. Also, the root account is always authenticated by means of the local security files.

The root account should always have a password, which should be selected with additional care. This is one of the few cases when random generator of password might be useful. 

There are multiple method of slightly increasing root account security. See Root Security. The best solution is provided by Solaris RBAC.

Attention: Routinely operating as the root user can result in accidental operation which damage the system to the extent making it unusable. See Admin Horror Storiesd  It is much safer to work from your own account, using  sudo for any operation that requires root privileges.

What the Superuser Can Do

Any process that has an effective UID of 0  runs as the superuser—that is, any process with a UID of 0 runs without security checks and is allowed to do almost anything. Normal security checks and constraints are ignored for the superuser, although most systems do audit and log some of the superuser's actions.

While it is generally understood that root can do anything, in reality those pawers are concentrted in two areas: process control and device control:

• Process control

  • Change runlevels.

  • Start, stop, and change the nice value of any process

  • Send any signal to any process including kill signal.

  • Alter "hard limits" for maximum CPU time as well as maximum file, data segment, stack segment, and core file sizes

  • Turn accounting and auditing on and off.

  • Change his process UID to that of any other user on the system.

  • Log out all users and prevent new logins.

• Device control

  • Access any working device.

  • Shut down or reboot the computer.

  • Set the date and time.

  • Read or modify any memory location.

  • Create new devices (anywhere in the filesystem) with the chmod( ) system call before the program can be run, although shell scripts can be run by feeding then directly into shell

  • Change a disk's electronic label.

  • Mount and unmount filesystems.

  • Add, remove, or change user accounts.

  • Enable or disable quotas and accounting.

What the Superuser Can't Do

There are also several things that the superuser can't do, including:

• Modify another user's files ACL. Only the owner of a file can modify the file ACL.

• Override mounting options such as read-only, nosuid, etc

  • Make a change to a filesystem that is mounted read-only. (However, the superuser can make changes directly to the raw device, or can unmount a read-only filesystem and remount it read/write, provided that the media is not physically write-protected.)
  • Create SUID files on a filesystem mounted as NOSUID.

• Unmount a filesystem that contains open files, or one in which some running process has set its current directory. You can find such files using lsof. Also many system provide forced unmount option.

• Write directly to a directory, or create a hard link to a directory.

• Retrive  the passwords stored in the shadow password file, although the superuser can change the password of any account.

• Terminate a process that has entered a wait state inside the kernel, although the superuser can shut down the computer, effectively killing all processes.

Root is just default username for superuser, Any Username Can Be a Superuser

You should immediately be suspicious of accounts on your system that have a UID of 0 that you did not install; accounts such as these are frequently added by people who break into computers so that they will have a simple way of obtaining superuser access in the future.

The Problem with the Superuser

The key problem with root account is not that is omnipotent but that regular user accounts are so powerless. So calling the root account the main security weakness in the Unix operating system is equivalent to barking to the wrong tree. 

At the same time there are some security issues related to having "omnipotent" account like root. Most Unix security exploits are based on the obtaining root privileges by exploiting some badly written or buggy program or interaction of several processes. Thus, most Unix security exploits result in a catastrophic failures of  server security mechanisms. It is enough to have a single unpatched program or component to compromise the entire computer (the weakest link effect).

There are a number of techniques for minimizing the impact of such system compromises, including:

• Storing sensitive files on encrypted (like some USB drives) or just removable media. In this case the exposure can be limited by the mounting the media only when you need to access sensitive files. This works well for those files that are accessed mainly during certain times of the year like tax returns.  An attacker who gains superuser privileges while the media is unmounted will not have access to critical files.

• Mounting /usr partition read only (this required symlinking /usr/local to /opt). Such practice is common on Solaris but not Linux.

• Encrypting your files. Even if the attacker gain access to the system he will not be able to decrypt encrypted archives such are zip, arj or rar archives. Best practice is to encrypt with a passphrase other than your login password, which an attacker might capture.

• Mounting disks read-only when possible.

• Mounting partitions that contain just user files as nosuid (home directories belong to this class of partitions).

• Taking advantage of filesystem features like BSD-style immutable attributes, which grant write access to the certain file only on low (maintenance) runlevels like 0 and 1.

• Keeping your backups current. This is a very important issue and is separately discussed elsewhere.

• Creating and maintaining baselines of your configuration files, which gives you the ability to use "time machine" approach to troubleshooting security related problems.

• Running the comparison against baseline on daily basis which notifies about important changed files (this should be program specific to the flavor of Unix used, as different Unixes have widely different behaviors in this area)

Overall, setting the secure level to 1 or 2 enables you to increase the overall security of a Unix system; it also makes the system dramatically harder to administer. If you need to take an action that's prohibited by the current security level, you must reboot the system to do so. Furthermore, the restrictions placed on the  root user at higher secure levels may not be sufficient; it may be possible, given enough persistence, for a determined attacker to circumvent the extra security that the secure level system provides. In this regard, setting the level higher may create a false sense of security that lulls the administrator into failing to put in the proper safeguards. Nevertheless, if you can run your system at a secure level higher than 0 without needing to constantly reboot it, it's probably worthwhile to do so.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Internals

• Root Security
• System Accounts
• Accounts security

BSD Kernel Security Levels

FreeBSD, Mac OS X, and other operating systems have kernel security levels, which can be used to significantly reduce the power that the system allots to the root  user. Using kernel security levels, you can decrease the chances that an attacker who gains root  access to your computer will be able to hide this fact in your logfiles.

The kernel security level starts at 0; it can be raised as part of the system startup, but never lowered. The secure level is set with the ;Level 1 is used for secure mode. Level 2 is used for "very secure" mode. Level 3 is defined as the "really-really secure mode."

At security level 1, the following restrictions are in place:

• Write access to the raw disk partitions is prohibited. (This forces all changes to the disk to go through the filesystem.).
• Raw access to the SCSI bus controller is prohibited.
• Files that have the immutable flag set cannot be changed. Files that have the append-only bit set can only be appended to, and not otherwise modified or deleted.
• The contents of IP packets cannot be logged.
• Raw I/O to the system console is prohibited.
• Raw writes to system memory or I/O device controllers from user programs are prohibited.
• Some access is denied to the Linux /proc filesystem.
• Additional kernel modules cannot be loaded.
• The system clock cannot be set backwards. In addition, it cannot be set forward more than a maximum of one second, and it can be set forward only once per second.

At security level 2, the following restriction is added: Reads from raw disk partitions are not permitted.

At security level 3, the following restriction is added:: Changes to the IP filter are not permitted.

This list is not comprehensive.

Linux Capabilities

Another mechanism for limiting the power of the superuser is the Linux capabilities system, invented on other operating systems five decades ago and included with the Linux 2.4 kernel. Some other high-security Unix systems and security add-ons to Unix have used capabilities for years, and the POSIX committee drafted a standard (POSIX 1003.1e) but later withdrew it.

The Linux capabilities system allows certain privileged tasks to be restricted to processes that have a specific "capability." This capability can be used, transferred to other processes, or given up. Once a process gives up a capability, it cannot regain that capability unless it gets a copy of the capability from another process that was similarly endowed. At startup, the

Some of the capabilities that a program can give up in the Linux 2.4.19 kernel are shown in Table 5-2. (This table also provides a nice illustration of the power of the superuser!)

Table 5-2. Some capabilities in Linux 2.4.19

Capability	Description
CAP_CHOWN	Can change file owner and group
CAP_FOWNER	Can override file restrictions based on file owner ID
CAP_FSETIDCAP_SETUIDCAP_SETGID	Can override requirements for setting SUID and SGID bits on files
CAP_KILL	Can send signals to any process
CAP_LINUX_IMMUTABLE	Can change the immutable or append-only attributes on files
CAP_NET_BIND_SERVICE	Can bind to TCP/UDP ports below 1024
CAP_NET_BROADCAST	Can transmit broadcasts
CAP_NET_ADMIN	Can configure interfaces, bind addresses, modify routing tables and packet filters, and otherwise manage networking
CAP_NET_RAW	Can use raw and packet sockets
CAP_IPC_LOCK	Can lock shared memory
CAP_IPC_OWNER	Can override IPC ownership checks
CAP_SYS_MODULE	Can load and remove kernel modules
CAP_SYS_CHROOT	Can use CAP_SYS_PTRACE	Can CAP_SYS_PACCT	Can enable, disable, or configure process accounting
CAP_SYS_ADMIN	Can configure disk quotas, configure kernel logging, set hostnames, mount and unmount filesystems, enable and disable swap, tune disk devices, access system bios, set up serial ports, and many other things
CAP_SYS_BOOT	Can use CAP_SYS_NICE	Can change process priorities and scheduling
CAP_SYS_RESOURCE	Can set or override limits on resources, quotas, reserved filesystem space, and other things
CAP_SYS_TIME	Can manipulate system clock
CAP_SYS_TTY_CONFIG	Can configure tty devices
CAP_SETPCAP	Can transfer or remove capabilities from any other process

 

Unfortunately, at the time this edition is being written, few Linux systems are designed to take advantage of the kernel capabilities and few system programs have been written to shed capabilities.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019