|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||Access Control||Recommended Links||Root account controls||Root Security||Solaris RBAC||ACL||Solaris ACLs||Linux ACL|
|Security Warning Banners||The /etc/passwd File||Managing user accounts in Perl||Dormant accounts||Accounts security||UID policy||System Accounts||Nobody Account||Sudo|
|Group administration||PAM||Authentication||Unix permissions model||Wheel Group||Sysadmin Horror Stories||Unix History||Humor||Etc|
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.
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:
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.
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.
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
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.
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 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.
Google matched content
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.
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
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
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.
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
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
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
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
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
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: October 03, 2017