LAST UPDATE: 20151108 SEE ALSO: http://www.dansher.com/utut/Internet_Security.txt ----------------------------------------------------------------- Please review the below so that some important UNIX/Linux features relating to User access and file security are familiar to all. The goal is to be sure that the UNIX terms outlined may be discussed with equal understanding by speakers and listeners alike. WHAT IS UNIX SECURITY? ---------------------- We must agree on the meaning for the term 'security', at least as it applies within the context of UNIX. Let it be this: SECURITY: THE PREVENTION OF PHYSICAL 'HARM' TO A GIVEN FILE OR DIRECTORY BY AN 'UNAUTHORIZED' USER. It must be clearly understood, and never forgotten, that there is no security whatsoever against 'harm' by a User who is 'authorized'. For perfect clarity our definition requires that the terms it uses also be defined: HARM: To alter or delete through ineptitude or malevolence. In this context 'harm' does not include the reading or duplication of any part or all of the file contents. AUTHORIZED: Any User whose login MEETS ANY ONE of these three conditions: (1) Is the "Super-User" (root), (2) Is the 'Owner' of that file (or directory), and/or (3) is a member of the 'Group' which has been assigned to that file (or directory). UNAUTHORIZED: Every User who FAILS ALL THREE of the conditions above. Note: The terms 'owner' and 'group' are explained in detail further below. THE UNIX USER-ENVIRONMENT ------------------------- All UNIX Users are assigned, at login, many default environmental variables such as "HOME" (e.g., /home/auser01) and "PATH" (the list of directories through which UNIX will search for requested program files). Other variables may be set (and possibly unset) by User-run programs (which may in turn run others). A User's environment DOES NOT control Security on UNIX. UNIX Security is defined only on a file by file, directory by directory, basis by the Owner (i.e., the creator) of each directory or file (or by root). A User's environment usually includes dozens of variables. The User may examine all the active variables (and the value each contains) in her current UNIX environment at any time with this command: env | sort | pg Every UNIX User has a "special" file: $HOME/.profile NOTE: Placing '$' in front of a variable name causes it to be seen by UNIX as the value contained by that variable (e.g., /home/auser01/.profile). When any User logs in, UNIX automatically runs his $HOME/.profile file. This is nothing more than a UNIX shell script, mostly used to assign values to new variables. The User's environment inherits those variables and their values. Any values of any variables which are exported (e.g., export PATH) can be used by other programs. For example if User Mary needs to access Oracle then her $HOME/.profile could be modified by any Authorized User such that her PATH variable included the necessary Oracle directories. Since Mary [usually] has Ownership of her $HOME/.profile she is Authorized and may therefore change its contents. Remember that the root login can read and/or change the content of any User's $HOME/.profile file (or any other for that matter). NOTE: The scope of UNIX Security can NOT altered in any way by the contents, or lack thereof, of any User's $HOME/.profile file. UNIX LOGINS ----------- The first levels of UNIX Security are the Login and Password requirements. It is possible (but seldom done) for the Super-User to restrict a User to activity within a single directory at login. The root login can also set the permissions and ownership of the User's $HOME/.profile file to prevent any changes being made to it. One or more variables within $HOME/.profile can also be set as "readonly" to prevent both the USER and programs from changing their values. It is a violation of Corporate Security (but not that of UNIX) to reveal or "share" one's UNIX login. Even so, Programmers and Administrators for the UNIX System and its Applications are often required to use several logins in the proper execution of their duties. Anyone who uses the login and password of someone else is considered by UNIX as Authorized for all the files and directories Owned by that 'someone else', including all files and directories belonging to the same Groups as those to which 'someone else' is permitted to belong. If you allow your login and password to become known by another, then you have only yourself to blame if some 'harm' eventually comes your way! CHANGING LOGINS ON THE FLY -------------------------- When duty requires, a User may use the "switch user" command to login as another User without first logging out. Example: su - aguru02 If the password for login aguru02 is successfully entered, then the original login inherits the complete environment, Ownership, and Groups of aguru02 NOTE: Every usage of the 'su' command is logged into the file /var/adm/sulog (including both successes and failures). If successful, the value of the $LOGNAME variable takes on the new identity while the command 'logname' always reveals how the User originally logged in. GROUP MEMBERSHIP - REVIEW AND CHANGE ------------------------------------ Any User can change his Group membership at will - but ONLY within the short list of Groups (usually only two, maybe three) which the Super-User has explicitly granted as permissable for that User. The User may choose only from among his list of Authorized Groups and can not, therefore, "extend" his security level beyond his pre-approved scope. A User may view his own list of allowed Groups with this command: groups -pg Placing the login of another User after the command above (e.g., groups -pg dweeb02) will display the Groups allowed for that User. A User's group-list probably contains one or more Groups in common with the Group-lists of one or more other User(s). To change the Group to which one's login is actively attached (i.e., the current Group), issue a command like: newgrp - bigeasy In this example, "bigeasy" may be any Group selected from among those so Authorized for that login. FILE AND DIRECTORY SECURITY --------------------------- UNIX Security is controlled exclusively on a file by file, directory by directory, basis by three "permission" masks for each of three user-classes: the file's Owner, its Group assignment, and all other Users (i.e., the "World") known to the system. "Long" file listings (e.g., as shown by ls -l) show complete Security (and other) information and will always look similar to this example: -rwxrw-r-- 1 dmarti01 amdusrs 1664594 Apr 25 16:23 icq98a.exe SECURITY LEVELS OWNER GROUP SIZE CREATED ON FILE NAME NOTE: If the first character on the left of the Security Levels is "d" (instead of a "-"), then the file is a directory (which is just a special type of file). File Security is displayed by a triad of nine "rwx" (read, write, execute) characters. The three triad-sets are shown in Owner, Group, and World user-class order. NOTE: a "-" in place of any rwx in one or more of the nine positions means the specific permission is denied to the entity within whose triad it appears. For the example shown several lines above, "-rwxrw-r--" means the Owner (dmarti01) may read, write, and execute (run) the file, Users in the same Group (amdusrs) can read and write (includes delete) to the file (but not run it), and all other Users (the "World") can only read (or copy) the file. NOTE: The Super-User enjoys effective "-rw-rw-rw-" Ownership of ALL files and directories, regardless of how the real Owner may have set the various permission-masks. Since other Users can change their groups (within the strict limits stated above), the wise User-Owner will carefully choose the "middle" set of "rwx" permissions (i.e., those for the Group) for every file and directory which she Owns. In the example further above, if "jhakkr01" is permitted to be a member of Group "amdusrs" then it would be possible for that User to delete the file "icq98a.exe". Fortunately, only a file's Owner (and root) can change the permission masks, the Ownership or the Group of a file or directory. If the three triads look like "-rw-------" (remember the first - shows that the item is a file and not a directory), then its Owner can read (or copy) and write (or delete) to the file but not run it (not all files are meant to be executed). All Users other than dmarti08 and root are therefore Unauthorized and can NOT alter, delete, read, or copy the file because all permissions for both the Group and World classes of Users have been denied. CHANGING FILE SECURITY ---------------------- Only the Owner of a file is, by definition, Authorized to change its Security Level (aka its "mode"). None of the file's Group members are so Authorized. The root login is always Authorized. Each of the four characters "rwx" and "-" are assigned unique numeric values (4, 2, 1, and 0 respectively) which makes it easy to change (or describe) the UNIX Security Level for any file. These values may be added together for each of the user-class triads in order to define the total Security Level (in other words, r + w + - = 4 + 2 + 0 = 6, the equivalent of "rw-" for a triad). Other examples: chmod 644 mine.txt sets the mode to "-rw-r--r--" for the file "mine.txt" chmod 666 mine.txt "-rw-rw-rw-" (loosest security) chmod 640 mine.txt "-rw-r-----" chmod 600 mine.txt "-rw-------" (strictest security) chmod 755 runsok.ksh "-rwxr-xr-x" (file to be run by all) chmod 754 runsok.ksh "-rwxr-xr--" and so on... If one says that "...file abcd is of mode 755..." then everyone knows that the file can be run by everyone but that only its Owner can make changes (i.e., write) to it. Changing the Group to which a file is assigned is simple for its Owner: chgrp bigeasy mine.txt The Owner may select from among any any Group listed in /etc/group and is not limited to just the short list of Groups that have been Authorized to him by the Super-User. If desired, the Owner of a file may "give it away" to another user with this command: chown myfile.c dude01 This conveys Ownership of "myfile.c" to the login "dude01" and instantly (and forever) prevents the file's former owner from ever changing its mode or Ownership again. At that moment the former owner can only enjoy whatever group and world permissions were set on the file at the moment the chown command was executed. EOF