|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||Root Account||Recommended Links||Wheel Group||Solaris RBAC|
|Sudo||PAM||Unix permissions model||Humor||Etc|
There are half-dozen classic ways to improve security of root account
PATHenvironment variable. Root's search path should be restricted to directories owned by root, such as
/usr/bin:/sbin:/usr/sbin, and you should generally use a fully justified filename when executing applications.
When this is done, all files or directories created by root will have permissions:
rwx------(if umask=077 is used)
In large corporate environment that main danger is the problem of shared root access: the situation when there are multiple administrators and application owners (the letter temporarily) can became root. Often members of such groups as database group and other application groups insist on being able to switch to root to perform specific tasks. This is a serious probloem does not have a clean solutions.
Sometimes you can use sudo to provide the ability to execute a selected program as root (for example Oracle installer), but generally this is difficult and almost unsolvable problem that creates many real SNAFUs with downtime and sometimes damage to data.
To grants temporary access to root a good method is to enroll particular person temporary into wheel group and provide in sudo passwordless switch to root for members of this group. First of all in this case you do not need to communicate the password. Secondly this is very useful feature foe sysadmin themselves, as one typical problem which sysadmin face with amazing regularity is when they need to access the server but nobody knows the root password for it. If wheel group is implemented in sudo as gateway to root you need to know only you account password, which is much easier task. This can be achieved by using the following directive in /etc/sudoers file:
%wheel ALL = (ALL) ALL
Some people are addicted to power and in IT environment this addiction demonstrates itself as a quest to obtain root access to as many systems as one can. It is very difficult to stop those people until a major incident occurs.
One important difference between external hackers and regular users is the set of IP addresses used. While this is not always true (zombie PC are pretty common those days) this is true enough to warrant some actions complicating break-ins from IP-space distinct from IP-space in which regular users of this system operate.
One solution is to disable direct access to your root ID for telnet, rsh and other client with non-encrypted clients and to limit ability to log-in to root using SSH to "trusted IPs" (static IPs on internal network which have records in DNS).
Please note that there is nothing wrong with using telnet by regular corporate users despite it being a less secure protocol then SSH (actually the number of successful break-ins via Open SSH exploits probably exceeds number of exploits using telnet; at one point OpenSSH exploits were the most popular way to break-in into ISPs ;-). This is connected with the fact that in a typical large corporate usage telnet is used either on the local network with dedicated IP space (usually 10.x.x.x network) or via VPN connection. In both situation attacks are possible but pretty difficult to execute:
That's why I suspect that all this cheap talk about telnet insecurity that is so popular in shallow security books and articles has somewhat weak connection to reality.
As ssh most often is compiled with TCP wrappers they can be used to limit IP space for the daemon.
The other method is that you can periodically reset root password using random password generator and to communicate it only when there is explicit need to use it (for example Tivoli client installations). In this case system administrators need to use sudo to obtain root privileges which limits the set of person eligible to the wheel group. Using sudo also allows you to monitor which users gained root access, as well as the time of their action. Su also has some logging capabilities and you can view su log ( /var/logs/sulog on Linux) and /var/adm/sulog on Solaris. Another alternative is to enable system auditing, which will report detailed activity for each account.
To disable remote login access for your root user, edit the /etc/security/access.conf file. It has quote a bit of interesting capabilities:
# Login access control table. # # Comment line must start with "#", no space at front. # Order of lines is important. # # When someone logs in, the table is scanned for the first entry that # matches the (user, host) combination, or, in case of non-networked # logins, the first entry that matches the (user, tty) combination. The # permissions field of that table entry determines whether the login will # be accepted or refused. # # Format of the login access control table is three fields separated by a # ":" character: # # [Note, if you supply a 'fieldsep=|' argument to the pam_access.so # module, you can change the field separation character to be # '|'. This is useful for configurations where you are trying to use # pam_access with X applications that provide PAM_TTY values that are # the display variable like "host:0".] # # permission : users : origins # # The first field should be a "+" (access granted) or "-" (access denied) # character. # # The second field should be a list of one or more login names, group # names, or ALL (always matches). A pattern of the form user@host is # matched when the login name matches the "user" part, and when the # "host" part matches the local machine name. # # The third field should be a list of one or more tty names (for # non-networked logins), host names, domain names (begin with "."), host # addresses, internet network numbers (end with "."), ALL (always # matches), NONE (matches no tty on non-networked logins) or # LOCAL (matches any string that does not contain a "." character). # # You can use @netgroupname in host or user patterns; this even works # for @usergroup@@hostgroup patterns. # # The EXCEPT operator makes it possible to write very compact rules. # # The group file is searched only when a name does not match that of the # logged-in user. Both the user's primary group is matched, as well as # groups in which users are explicitly listed. # # TTY NAMES: Must be in the form returned by ttyname(3) less the initial # "/dev" (e.g. tty1 or vc/1) # ############################################################################## # # Disallow non-root logins on tty1 # #-:ALL EXCEPT root:tty1 # # Disallow console logins to all but a few accounts. # #-:ALL EXCEPT wheel shutdown sync:LOCAL # # Disallow non-local logins to privileged accounts (group wheel). # #-:wheel:ALL EXCEPT LOCAL .win.tue.nl # # Some accounts are not allowed to login from anywhere: # #-:wsbscaro wsbsecr wsbspac wsbsym wscosor wstaiwde:ALL # # All other accounts are allowed to login from anywhere. # ############################################################################## # All lines from here up to the end are building a more complex example. ############################################################################## # # User "root" should be allowed to get access via cron .. tty5 tty6. #+ : root : cron crond :0 tty1 tty2 tty3 tty4 tty5 tty6 # # User "root" should be allowed to get access from hosts with ip addresses. #+ : root : 192.168.200.1 192.168.200.4 192.168.200.9 #+ : root : 127.0.0.1 # # User "root" should get access from network 192.168.201. # This term will be evaluated by string matching. # comment: It might be better to use network/netmask instead. # The same is 192.168.201.0/24 or 192.168.201.0/255.255.255.0 #+ : root : 192.168.201. # # User "root" should be able to have access from domain. # Uses string matching also. #+ : root : .foo.bar.org # # User "root" should be denied to get access from all other sources. #- : root : ALL # # User "foo" and members of netgroup "nis_group" should be # allowed to get access from all sources. # This will only work if netgroup service is available. #+ : @nis_group foo : ALL # # User "john" should get access from ipv4 net/mask #+ : john : 127.0.0.0/24 # # User "john" should get access from ipv4 as ipv6 net/mask #+ : john : ::ffff:127.0.0.0/127 # # User "john" should get access from ipv6 host address #+ : john : 2001:4ca0:0:101::1 # # User "john" should get access from ipv6 host address (same as above) #+ : john : 2001:4ca0:0:101:0:0:0:1 # # User "john" should get access from ipv6 net/mask #+ : john : 2001:4ca0:0:101::/64 # # All other users should be denied to get access from all sources. #- : ALL : ALL
Before you disable the remote root login, examine and plan for situations that would prevent a system administrator from logging in under a non-root user ID. For example, if a user's home file system is full, the user would not be able to log in. If the remote root login were disabled and the user who could use the su - command to change to root had a full home file system, root could never take control of the system. This issue can be bypassed by system administrators creating home file systems for themselves that are larger than the average user's file system.
For more information about controlling root login, see System Configuration for a CAPP/EAL4+ System.
Root account should be protected from remote exploits as much as possible (no direct remote login other then ssh with certificate, etc).
Most versions of Unix allow you to configure certain terminals so that users can't log in as the superuser from the login : prompt. Anyone who wishes to have superuser privileges must first log in as himself and then use su to root. This feature makes tracking who is using the root account easier Network virtual terminals should not be listed as secure to prevent users from logging into the root account remotely using telnet . The Secure Shell server ignores the terminal security attribute, but it has its own directive (PermitRootLogin in sshd_config ) that controls whether users may log in as root remotely.
On System V-derived systems, terminal security is specified in the file /etc/securetty . In general, most Unix systems today are configured so that the superuser can log in with the root account on the system console, but not on other terminals. Even if your system allows users to log directly into the root account, we recommend that you institute rules that require users to first log into their own accounts and then use the
Because every UNIX system has an account named root , this account is often a starting point for people who try to break into a system by guessing passwords. One way to decrease the chance of this is to restrict logins from all but physically guarded terminals. If a terminal is marked as restricted, the superuser cannot log into that terminal from the login: prompt. (However, a legitimate user who knows the superuser password can still use the su command on that terminal after first logging in.)
On a SVR4 machine, you can restrict the ability of users to log in to the root account from any terminal other than the console. You accomplish this by editing the file /etc/default/loginand inserting the line:
This line prevents anyone from logging in as root on any terminal other than the console. If the console is not safe, you may set this to the pathname of a nonexistent terminal.
Some older Berkeley-derived versions of UNIX allow you to declare terminal lines and network ports as either secure or not secure . You declare a terminal secure by appending the word "secure" to the terminal's definition in the file /etc/ttys
In this example taken from a /etc/ttys file, terminal tty01 is secure and terminal tty02 is not. This means that root can log into terminal tty01 but not tty02 .
Note that after changing the /etc/ttys file, you may need to send out a signal to initialize before the changes will take effect. On a BSD-derived system, run:
kill -1 1
Other systems vary, so check your own system's documentation.
You should carefully consider which terminals are declared secure. Terminals in public areas should also not be declared secure. Being "not secure" does not prevent a person from executing commands as the superuser: it simply forces users to log in as themselves and then use the su command to become root . This method adds an extra layer of protection and accounting.
On the other hand, if your computer has a terminal in a special machine room, you may wish to make this terminal secure so you can quickly use it to log into the superuser account without having first to log into your own account.
NOTE: Many versions of UNIX require that you type the superuser password when booting in single-user mode if the console is not listed as "secure" in the /etc/ttys file. Obviously, if you do not mark your console "secure," you enhance your system's security.
Consider the case where we approach a terminal in multi-terminal environment (like used to be common at universities) and wish to login to the system. What if someone has left a spoof login running in his terminal session. If the spoof is carefully programmed you will not be able to tell the difference until the damage is done. Such problem with the programs that mimic the login program behavior are common to all operating systems. In Windows environment where login are typically performed in GUI environment vendors produce complex animated pictures that make it more difficult to write a spoof.
In any case if you are not using one-time passwords or tokens, this way you can give an intruder access to your account.
AIX can be configured to recognize a special signal from real terminals (including workstation consoles) for this purpose. When the signal (usually a BREAK, or some sequence of control characters) is received by the low-level terminal driver, the driver sends an unstoppable signal to all processes still connected to the terminal, that terminates them. Thereafter, a new session is started and the user can be assured that the next prompt for a login is from the real system software.
For this mechanism to work, you should access real terminal: networked connection can still be intercepted and spoofed.
Here is a long quote from Red Hat document Administrative Controlswhich explains issues more or less well:
Allowing Root Access
If the users within an organization are a trusted, computer-savvy group, then allowing them root access may not be an issue. Allowing root access by users means that minor activities, like adding devices or configuring network interfaces, can be handled by the individual users, leaving system administrators free to deal with network security and other important issues.
On the other hand, giving root access to individual users can lead to the following issues:
4.4.2. Disallowing Root Access
- Machine Misconfiguration— Users with root access can misconfigure their machines and require assistance or worse, open up security holes without knowing it.
- Running Insecure Services— Users with root access may run insecure servers on their machine, such as FTP or Telnet, potentially putting usernames and passwords at risk as they pass over the network in the clear.
- Running Email Attachments As Root— Although rare, email viruses that affect Linux do exist. The only time they are a threat, however, is when they are run by the root user.
If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret and access to runlevel one or single user mode should be disallowed through boot loader password protection (refer to Section 4.2.2 Boot Loader Passwordsfor more on this topic.)
Table 4-1shows ways an administrator can further ensure that root logins are disallowed:
Method Description Effects Does Not Affect Changing the root shell. Edit the /etc/passwd file and change the shell from /bin/bash to /sbin/nologin .
Prevents access to the root shell and logs the attempt. The following programs are prevented from accessing the root account: login gdm kdm xdm su ssh scp sftp
Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs. The following programs are notprevented from accessing the root account: sudo FTP clients Email clients
Disabling root access via any console device (tty). An empty /etc/securetty file prevents root login on any devices attached to the computer.
Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account: login gdm kdm xdm Other network services that open a tty
Programs that do not log in as root, but perform administrative tasks through through setuid or other mechanisms. The following programs are notprevented from accessing the root account: su sudo ssh scp sftp
Disabling root SSH logins. Edit the /etc/ssh/sshd_config file and set the PermitRootLogin parameter to no .
Prevents root access via the OpenSSH suite of tools. The following programs are prevented from accessing the root account: ssh scp sftp
This only prevents root access to the OpenSSH suite of tools.
Use PAM to limit root access to services. Edit the file for the target service in the /etc/pam.d/ directory. Make sure the pam_listfile.so is required for authentication.[a]
Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account: FTP clients Email clients login gdm kdm xdm ssh scp sftp Any PAM aware services
Programs and services that are not PAM aware.
a. Refer to Section 188.8.131.52 Disabling Root Using PAMfor details.
Table 4-1. Methods of Disabling the Root Account184.108.40.206. Disabling the Root Shell
To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file. This prevents access to the root account through commands that require a shell, such as the su and the ssh commands.
Important Programs that do not require access to the shell, such as email clients or the sudo command, can still access the root account.
220.127.116.11. Disabling Root Logins
To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous as a user can login into his machine as root via Telnet, which sends his password in plain text over the network. By default, Red Hat Enterprise Linux's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:echo > /etc/securetty
Warning A blank /etc/securetty file does notprevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. 18.104.22.168. Disabling Root SSH Logins
To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file (/etc/ssh/sshd_config ). Change the line that reads:PermitRootLogin yes
to read as follows:PermitRootLogin noDisabling Root Using PAM
PAM, through the /lib/security/pam_listfile.so module, allows great flexibility in denying specific accounts. This allows the administrator to point the module at a list of users who are not allowed to log in. Below is an example of how the module is used for the vsftpd FTP server in the /etc/pam.d/vsftpd PAM configuration file (the \character at the end of the first line in the following example is notnecessary if the directive is on one line):auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
This tells PAM to consult the file /etc/vsftpd.ftpusers and deny access to the service for any user listed. The administrator is free to change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.
If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration services, such as /etc/pam.d/pop and /etc/pam.d/imap for mail clients or /etc/pam.d/ssh for SSH clients.
For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM)in the Red Hat Enterprise Linux Reference Guide.
4.4.3. Limiting Root Access
Rather than completely deny access to the root user, the administrator may want to allow access only via setuid programs, such as su or sudo .22.214.171.124. The su Command
Upon typing the su command, the user is prompted for the root password and, after authentication, is given a root shell prompt.
Once logged in via the su command, the user isthe root user and has absolute administrative access to the system. In addition, once a user has become root, it is possible for them to use the su command to change to any other user on the system without being prompted for a password.
Because this program is so powerful, administrators within an organization may wish to limit who has access to the command.
One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:usermod -G wheel <username>
In the previous command, replace <username>with the username you want to add to the wheel group.
To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command system-config-users at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).
Then select the Groups tab and click on the wheel group
Next, open the PAM configuration file for su (/etc/pam.d/su ) in a text editor and remove the comment [#] from the following line:auth required /lib/security/$ISA/pam_wheel.so use_uid
Doing this permits only members of the administrative group wheel to use the program.Note: The root user is part of the wheelgroup by default.
Keeping the superuser account secure should be a top priority for any system.
The most sought-after account on your machine is the superuser account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea.
Several tricks to avoid messing up your own box as root:
- When doing some complex command, try running it first in a non destructive way...especially commands that use globbing: e.g., you are going to do a rm foo*.bak, instead, first do: ls foo*.bak and make sure you are going to delete the files you think you are. Using echo in place of destructive commands also works.
- Provide your users with a default alias to the /bin/rm command to ask for confirmation for deletion of files.
- Only become root to do single specific tasks. If you find yourself trying to figure out how to do something, go back to a normal user shell until you are sure what needs to be done by root.
- The command path for the root user is very important. The command path, or the PATH environment variable, defines the location the shell searches for programs. Try and limit the command path for the root user as much as possible, and never use '.', meaning 'the current directory', in your PATH statement. Additionally, never have writable directories in your search path, as this can allow attackers to modify or place new binaries in your search path, allowing them to run as root the next time you run that command.
- Never use the rlogin/rsh/rexec (called the "r-utilities") suite of tools as root. They are subject to many sorts of attacks, and are downright dangerous run as root. Never create a .rhosts file for root.
- The /etc/securetty file contains a list of terminals that root can login from. By default (on Red Hat Linux) this is set to only the local virtual consoles (vtys). Be very careful of adding anything else to this file. You should be able to login remotely as your regular user account and then use su if you need to (hopefully over ssh or other encrypted channel), so there is no need to be able to login directly as root.
- Always be slow and deliberate running as root. Your actions could affect a lot of things. Think before you type!
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.
Created: May 16, 1997; Last modified: September 12, 2017