|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||Red Hat Certification Program||Understanding and using essential tools||Access a shell prompt and issue commands with correct syntax||Finding Help||Managing files in RHEL||Working with hard and soft links||Working with archives and compressed files||Using the Midnight Commander as file manager|
|Text files processing||Using redirection and pipes||Use grep and extended regular expressions to analyze text files||Finding files and directories; mass operations on files||Connecting to the server via ssh, using multiple consoles and screen command||Introduction to Unix permissions model||VIM: Basic and intermediate set of command for syadmins||Managing local users and groups|
|Tips||Sysadmin Horror Stories||Unix History with some Emphasis on Scripting||Humor||Etc|
Unix borrowed from CTSS a simple model of file permissions and somewhat extended it. This model which is called "Classic Unix Permissions Model." It has proven to be amazingly effective, flexible and relatively easy to understand. All those three signs of great design are present in it. And in retrospect it proved to be not that simple. But it is still within intellectual capabilities of most Unix sysadmins. That's a great achievements, the level far above many alternatives and extensions. It does possesses conceptual integrity (the sign of high level of architectural design) and survived the test of the time.
Because file permissions determine who can read and modify the information stored in the files in the particular Linux system, they are the primary method for protecting the data.
Relatively recently it was extended with ACLs to compensate for some of its fundamental weakness: file can belong only to a single group. ACL model is similar to approach to file permissions that is used in Windows but it is so complex, that very few organization have adopted this approach on Unix servers belong some trivial cases of exported via Samba or NFS filesystems. So instead of useful addition ACL became the major security threat. Very few sysadmins understand it, and that create vast open space for hackers who have time and desire to study them for months or even years for creating backdoors. The is classic "the road to hell is paved with good intentions" situation, which had shown critical importance of complexity in operating system permission model: the existence of two models in Unix is an additional (and huge) security risk. The effect quite opposite of intentions. That means that all files with ACLs on important server should be regularly audited for unauthorized changes of those permissions. For the same reason ACL is generally a bad idea for SUID-root files (see below). Sudo is a safer path to allow additional users to execute them.
Most people think that file permissions are pretty easy stuff. That's not true. On large system even simple staff become mind-bogglingly complex. Many linux servers systems have had security breaches because their file permissions were not properly set, or were changed for "easy" access. There are several automated tools which help with checking the permissions of important system files and directories. Typically they are part of so called hardening packages. That should be done on regular basis.
Classic Unix model specified thee group of permission -- user(owner, group and other (everbody else). All three groups of permissions for a given file in turn consist of three separately granted rights:
File permissions also apply to devices, named sockets, and FIFOs exactly as they do for regular files. If you have write access, you can write information to the file or other object; if you have read access, you can read from it
Each permission is encoded by one bot. So it takes 9 bits to specify all permission. They are often listed in octal notation. For example 777 means that all permissions are granted 000 -- means that none is granted. The decoding is simple:
|Octal value||Binary value||Meaning|
Note the following important two facts about file permissions:
This behaviour is very important for files that have SUID bit set as copying such file to your home directory is common way to obtain a backdoor to the system (the typical unauthorized file with SUID set that is often copied to obtain a backdoor to the system is shell; the third rule means that you can do it only as root, so you need to obtain unauthorized root access first to perform this trick).
But there is an interesting nuance here -- if file has SUID and owner is set to root, copying of the file by any user who is not root lead to both the loss of SUID bit the loss of ownership of the file by the root. So in even very simple and straightforward model has tricky "use cases." That suggest that ACL, a "bolted on" windows style permission system which are much more complex, is a real swamp which can consume even reasonably talented sysadmins with ease.
While simple and effective Unix permission model is still above the head of many people, especially if many groups are involved in the project. Quick fix used is suhc situation is to set permission to 777, which means disabling any access control. This is definitely a very bad solution, and in no way it can be recommended in any circumstances. This sad reality is actually pretty typical for some large US corporations, especially their research arms. Attempts to fix this situation required pretty high level of understanding what Unix permission model is about and how it operated, because of the level of user resistance.
In Unix each file has three categories of access plus modifiers for this access in a form of special attributes:
The are also three attributes for each of three access categories (owner, group and world):
The first two bytes of an executable file are assumed to be a magic number indicating the nature of the file. Some numbers mean that the file is a certain kind of machine code file. The special two-byte sequence "#!" means that it is a script and that the remainder of the first line specifies the program that should interpret the script. Anything with an unknown value is assumed to be a shell script and is interpreted by the default shell.
The execution bit on the directory not set, this essentially works as partial access control for files in this directory: there is no way to obtain a listing of the directory although if you know file name you can access and execute the file.
It is important to understand that the ability to delete file/directory normally is a property not of a file/directory in question, but the directory in which it contained. It the user has write access to the directory he/she can delete any file in it. this behaviour can be changes by marking the directory with sticky bit (typically /tmp) is marked with sticky bit) which blocks the ability of users other then owner of the file to delete file, this substituting the owner defined by the directory with the owner defined by the file.
One of limitations of the Unix model is that ordinary users do not have the right to make their own groups, because the groups does not have the notion of owner and it is impossible to distinguish which groups were created by the root and which by the user. So if the user wants to grant access to particular file to people outside the groups that exist on the system, he/she can only grant access to everybody via "world" set of permissions. This is where Classic Unix permission model shoots itself in the foot. There are ways around this, but Unix has not introduced a standard solution to the problem. Yet.
So you can see that even simple and elegant solution such classic Unix permission model has some tricky issues and at retrospect does not looks such a simple concept as initially. As always the devil is in the details.
Permission are normally changed using chmod command and octal notation for them is dominant.
Normally sysadmin sets file permission using octal notation. But sometime is it more convenient to use symbolic notation. This is the case, for example, when you want to change only one permission in the group and do not touch any other, leaving them "as-is". For example you might wish to remove write permission form file.
When chmod command is invoked using symbolic notation, it will modify or set the flags as specified by the maskExpression with the syntax
Multiple maskExpressions are separated by commas.
A space terminates the maskExpression (s).
|g||group||users who are members of the file's group|
|o||others||users who are not the owner of the file or members of the group|
|a||all||all three of the above, the same as ugo.|
|+||permissions specified are enabled, permissions that are not specified are unchanged.|
|-||permissions specified are disabled, permissions that are not specified are unchanged.|
|=||permissions specified are enabled, permissions that are not specified are disabled.|
|r||read||read a file or list a directory's contents|
|w||write||write to a file or directory|
|x||execute||execute a file or recurse a directory tree|
|s||setuid/gid||Set SUID of SGID attribute|
|t||sticky||Set sticky bit|
chmod u-w ~.bash_profile
To understand this model we need to understand notion of UID (user id) and GID (group id). Both are integers with minimal equal 0 and which max set to a certain (but very high) value. I think 64 bit integers are now used for both. Rood has UID 0. There is also group root which has GID 0. File with UID 0, GID 0 are typically the most protected class of files in Unix.
In the original Unix model, each file there are three types of access permission: User (u), Group (g) and Other (o). Group is essentially a label for the role and defines a set of user that should have access to particular file (which is a definition of role). This way we can talk about such roles of webmaster (who needs to have access to LAMP stack -- Apache, MySQL and PHP), data base administrator (who need to have access to particular set of databases used on the server, for example MySQL and Oracle). Programmer is also a role and he/she needs access to compilers, scripting languages, make utility, and such. In real organizations those groups can intersect and that creates major problems with classic Unix permission model as any in this model group is atomic -- can consist only of individual users, not the other groups.
In other words, any user can be a member of any number of groups, but unfortunately groups can't contain other groups. So all groups in Unix are "atomic" consisting of only users. This is a well known weakness of the Classic Unix Permissions Model. Of course, you can "precompile" /etc/group file creating the ability to use other groups as members of groups via special script which explains then to list of users. This way you can introduce "metagroups" -- groups that are aggregations of existing groups and users. But that solution requires additional efforts and discipline (in this case /etc/group need to be automatically generated from some template with macros). If we assume that the number of group allowed is large -- approximately the same as the number of files/directories, then this metagroup approach is as powerful as ACL model and is much simpler. It requires relatively simple modification of the /etc/group file.
Unix essentially ha only one special user -- superuser or root. Some flavor of Unix like Solaris have more flexible subsystem called RBAC (role based access control), but in Linux this is not the case.
There is also auxiliary concept of system groups which is similar to the concept of privileged ports. We can attach special privileges to such groups. It is also possible to assign special meaning to certain integer intervals for the purpose of auditing of system activity.
For example, all groups with GID below 100 are often considered to be system groups and files which are owned by those users are considered system files (Unix does not have system attributed like Windows, but this rule can compensate for this shortcoming). You can enforce special rules for deletion of such files, using some king of wrappers over system command like rm. This is important because wiping out of the system due to Creative uses of rm is major problem that each Linux sysadmin sooner or later faces (see Sysadmin Horror Stories )
By default RHEL7 contains around 50 system groups:
root:x:0: bin:x:1: daemon:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: mem:x:8: kmem:x:9: wheel:x:10: cdrom:x:11: man:x:15: dialout:x:18: floppy:x:19: games:x:20: tape:x:30: video:x:39: lock:x:54: audio:x:63: users:x:100: utmp:x:22: utempter:x:35: ssh_keys:x:999: input:x:998: systemd-journal:x:190: systemd-bus-proxy:x:997: systemd-network:x:192: dbus:x:81: polkitd:x:996: libstoragemgmt:x:995: printadmin:x:993: abrt:x:173: tss:x:59: dip:x:40:
That's way too many. Among them are groups that have GID above 100 .
ssh_keys:x:999: input:x:998: systemd-journal:x:190: systemd-bus-proxy:x:997: systemd-network:x:192: dbus:x:81: polkitd:x:996: libstoragemgmt:x:995: printadmin:x:993: abrt:x:173:
Some groups an be classified as applications accounts for system daemons although the boundary is really fuzzy here:
slocate:x:21: rpc:x:32: apache:x:48: sshd:x:74: postdrop:x:90: postfix:x:89: ntp:x:38: chrony:x:994: tcpdump:x:72: screen:x:84:In any case you can see that Red Hat is a complexity junky and RHEL7 reflects this addition to complexity.
Some system groups were introduced mainly for partitioning of permission space: groups as root, sys, adm, bin, daemon, etc do not have any members and they have no legitimate shell ( /bin/noshell or /bin/false is used instead in /etc/passwd), so nobody can login as such a user.
In other words the numeric value of group is used in Linux and other flavors of Unix to partition groups into two categories with lower value groups considered to be system groups. This is a compensation for missing "system" attribute in files.
The idea of system group is somewhat similar to the idea to the idea of privileged ports and despite its simplicity it is quite powerful and allow performance of the additional checks via PAM mechanism that increases security.
One important system group which is identified by its name and not by its GID is called wheel. In RHEL it has GID 10. It contains the list of system administrators for the server (users who have legitimate rights to become root) and is usually used (via sudo) to give this subset of users the ability to switch to root, independently whether they know root password or not. This idea of wheel group like many other brilliant ideas came from BSD. Another group that often has extended privileges via sudo in the operator group, but its semantic is less well defined.
Every directory and file on the system has an owner, and also an associated group. It also has a as additional three permission flags which modify the meaning of specified res/write/execute permissions for the 'user' (SUID) 'group' (SGID), and 'other' (sticky bit).
The 'ls' command shows the permissions including sticky bits set, as well as owner and the group associated with file(s) when used with the -l option.
Here's another typical example of sticky bit usage: the user skeptic makes
a world-writable directory and sets the sticky bit (shown as
t here) to share files with members of the group staff:
chmod 1775 perl_scripts%
ls -ld perl_scripts
% chown :staff perl_scripts
drwxrwxrwt 2 skeptic staff 32 Nov 19 10:31 share
Now members of the group staff can create files in it, but they cannot delete files owned by other people.
NOTE: The sticky bit got its name on early Unix systems in the days before demand-paged virtual memory. If the sticky bit of an executable file was set, after the program exited a copy of its text segment was saved in the system's swap area, i.e., it would ``stick around'' for the next use. This feature was used to make frequently-run programs load a little bit faster. This meaning of the sticky bit is no longer relevant.
In Unix umask controls how file permissions are set for newly created files. the structure of the mask is identical to structure of file permissions. This concept was introduced around 1978, between the sixth edition and the eighth edition of the operating system. Like regular file permissions umask can be represented in binary, octal or symbolic notation. And the umask command allows the mask to be set in all three notations.
It may be changed by invoking the umask command. The syntax of the command is:
umask [-S ] [maskExpression]
The items within the brackets are optional. The -S argument (i.e. umask -S) will force umask to display using symbolic notation
If the umask command is invoked without any arguments, it will display the current mask.
$ umask # display current value (as octal) 0022 $ umask -S # display current value symbolically u=rwx,g=rx,o=rx
If the umask command is invoked with an argument, it set the bits of the mask to that argument. For example:
$ umask 007 # set the mask to 007 $ umask # display the mask (in octal) 0007 # 0 - special permissions (setuid | setgid | sticky ) # 0 - (u)ser/owner part of mask # 0 - (g)roup part of mask # 7 - (o)thers/not-in-group part of mask $ umask -S # display the mask symbolically u=rwx,g=rwx,o=
If fewer than 4 digits are entered, leading zeros are assumed. An error will result if the argument is not a valid octal number or if it has more than 4 digits. If a fourth digit is present, the leftmost (high-order) digit defines three additional attributes, the setuid bit, the setgid bit and the sticky bit.
|Octal digit in
|Permissions the mask will
prohibit from being set during file creation
|0||any permission may be set (read, write, execute)|
|1||setting of execute permission is prohibited (read and write)|
|2||setting of write permission is prohibited (read and execute)|
|3||setting of write and execute permission is prohibited (read only)|
|4||setting of read permission is prohibited (write and execute)|
|5||setting of read and execute permission is prohibited (write only)|
|6||setting of read and write permission is prohibited (execute only)|
|7||all permissions are prohibited from being set (no permissions)|
Prohibit write permission from being set for the user. The rest of the flags in the mask are unchanged.
Example of multiple changes:
This would set the mask so that it would:
Here are more examples of using the umask command to change the mask.
|umask command issued||How the mask will affect permissions of subsequently created files/directories|
|umask a+r||allows read permission to be enabled for all user classes; the rest of the mask bits are unchanged|
|umask a-x||prohibits enabling execute permission for all user classes; the rest of the mask bits are unchanged|
|umask a+rw||allows read or write permission to be enabled for all user classes; the rest of the mask bits are unchanged|
|umask +rwx||allows read, write or execute permission to be enabled for all user classes; (Note: On some UNIX platforms, this will restore the mask to a default.)|
|umask u=rw,go=||allow read and write permission to be enabled for the owner, while prohibiting execute permission from being enabled for the owner; prohibit enabling any permissions for the group and others|
|umask u+w,go-w||allow write permission to be enabled for the owner; prohibit write permission from being enabled for the group and others;|
|umask -S||display the current umask in symbolic notation|
|umask 777||disallow read, write, and execute permission for all (probably not useful because even owner cannot read files created with this mask!)|
|umask 000||allow read, write, and execute permission for all (potential security risk)|
|umask 077||allow read, write, and execute permission for the file's owner, but prohibit read, write, and execute permission for everyone else|
|umask 113||allow read or write permission to be enabled for the owner and the group, but not execute permission; allow read permission to be enabled for others, but not write or execute permission|
|umask 0755||equivalent to u-rwx (4+2+1),go=w (4+1 & 4+1). (The 0 specifies that special modes[clarify] may be enabled if allowed by the OS.)|
Example showing effect of umask:
$ umask -S # Show the (frequently initial) setting u=rwx,g=rx,o=rx $ gcc hello.c # compile and create executable file a.out $ ls -l a.out -rwxr-xr-x 1 me developer 6010 Jul 10 17:10 a.out $ # the umask prohibited Write permission for Group and Others $ ls > listOfMyFiles # output file created by redirection does not attempt to set eXecute $ ls -l listOfMyFiles -rw-r--r-- 1 me developer 6010 Jul 10 17:14 listOfMyFiles $ # the umask prohibited Write permission for Group and Others $ ############################################################ $ umask u-w # remove user write permission from umask $ umask -S u=rx,g=rx,o=rx $ ls > protectedListOfFiles $ ls -l protectedListOfFiles -r--r--r-- 1 me developer 6010 Jul 10 17:15 protectedListOfFiles $ rm listOfMyFiles override r--r--r-- me/developer for protectedListOfFiles? $ # warning that protectedListOfFiles is not writable, answering Y will remove the file $ ##################################################################################### $ umask g-r,o-r # removed group read and other read from mask $ umask -S u=rx,g=x,o=x $ ls > secretListOfFiles $ ls -l secretListOfFiles -r-------- 1 me developer 6010 Jul 10 17:16 secretListOfFiles
The mask is applied whenever a file is created. If the mask has a bit set to "1", that means the corresponding file permission will always be disabled when files are subsequently created. A bit set to "0" in the mask means that the corresponding permission will be determined by the requesting process and the OS when files are subsequently created. In other words, the mask acts as a last-stage filter that strips away permissions as a file is created; each bit that is set to a "1" strips away that corresponding permission for the file.
One of the most interesting aspects of file security is the matter of what security attributes are inherited by new files and the sources of this inheritance. New files created by the users have to start out with some set of permissions. There are two models of accomplishing this task -- BSD and SysV
Those days there are no pure BSD/SysV systems left. Most systems are hybrid.
This is quite recent attempt to extend the Classic Unix model busing a very simple idea: user primary group should be unique and contin only this particular user and no other users. This is the concept behind so called User Private Groups (UPG) initially introduced in Red Hat, but abandoned in RHEL6. This is an interesting idea -- a new convention for assigning primary groups to real (human) users: each of them gets unique primary group with the GID value equal to their UID. Whenever you create a new user, by default, he or she is assigned a unique group that has GID equal to UID.
Assuming each user is the only member of its user private group, this scheme allows an umask of 002 to be used without allowing other users to write to newly created files in normal directories because such files are assigned to the creating user's private group. However, when sharing files is desirable, the administrator can create a group containing the desired users, create a group-writable directory assigned to the new group, and, most importantly, assign to the directory SETGID bit.
Such scheme makes removal of users much easier. It also makes home directories more secure, as by default they are assigned the value of user primary group. If this group contains other users (for example, if this group is users), they all acquire access to this particular user home directory, unless group permissions are set to 0 or you have a very strict umask for the system. This is just a procedural enhancement, which does not add or change anything in the standard UNIX way of handling groups but like other useful procedural enhancement such as special role of wheel group or system groups, it increases the security and flexibility of Unix classic permission model.
Again, as groups assignment is essentially assignment of roles in large organizations is it might bogglingly complex. Often it is screwed up in major way -- for example group is assigned based on organizational unit in Active Directory. Which for some users is too restrictive but for other users way too permissive. At the end of the day it leads to excessive number of users who have access to root via sudo, as they can't accomplish their job within a straitjacket put by their group membership.
Whether you can read the contents of a file pointed to by a symbolic link depends on that file's permissions, not the link's. In fact, symbolic links are created with a file permission of "rwxrwxrwx" (or mode 0777). These file permissions are ignored by the operating system.
In ls listing each specification of permissions for the particular file is usually called "file mode" and it occupies 7 bytes, Here are two examples of file mode:
The first character of the file's mode field in ls listing indicates the type of file:
Character device (tty or printer)
Block device (usually disk or CD-ROM)
= or p
FIFO (System V, Linux)
The next nine characters are actually three groups of three character each and indicate read, write, and execute permissions for owner, group and "the world" or "others". S means that SUID or SGID bit is set. 't' means sticky bit is set.
For example, there are several files with SUID root in /usr/bin directory of RHEL7. They all have the third letter of owner permissions changed to 's':
bezroun@test01:/usr/bin # ll | grep rws -rwsr-xr-x. 1 root root 52K Apr 11 2018 at* -rwsr-xr-x. 1 root root 63K Nov 5 2016 chage* -rws--x--x. 1 root root 24K Aug 16 18:47 chfn* -rws--x--x. 1 root root 24K Aug 16 18:47 chsh* -rwsr-xr-x. 1 root root 57K Apr 11 2018 crontab* -rwsr-xr-x. 1 root root 77K Nov 5 2016 gpasswd* -rwsr-xr-x. 1 root root 44K Aug 16 18:47 mount* -rwsr-xr-x. 1 root root 41K Nov 5 2016 newgrp* -rwsr-xr-x. 1 root root 28K Jun 10 2014 passwd* -rwsr-xr-x. 1 root root 28K Apr 11 2018 pkexec* -rwsr-xr-x. 1 root root 32K Aug 16 18:47 su* -rwsr-xr-x. 1 root root 32K Aug 16 18:47 umount*
If ACL attributes are present there is an additional character "+" following the permission characters for "other" in ls -l listing:
-rwx--x--x+ 3 root root 24219 May 17 00:52 example
In the example above the + symbol indicates that this file (or other item) has an ACL associated with it. An Access Control List (ACL) provides a more comprehensive set of permissions on the file than can be described with the single user/single group model.
Permission are interpreted in the order -- owner, group, other. If at some point you are allowed or denied the requested access based on you file ownership or membership, other permissions are not interpreted. In case you are denied access you are simply out of luck. For example, if the file has the owner permissions set to rw-, and you are the owner and try to execute it, you will be denied access even if you are member of the group specified for the file and that that group has requested access say read access to the file). If you are denied access as the member of the group specified, it does not matter for you what "other permissions are set", you are still out of luck. Of course, if you are the owner nothing prevents you from changing permissions for this file, so the first example with owner is kind of artificial.
That means that permission 005 means: anybody but the owner and the members of the group can read and execute this file.
Unix stores the contents of directories in nodes that are similar to the nodes used for regular files, but they are specially marked so that they can be modified only by the operating system.
As with other files, directories have a full complement of security attributes: owner, group, and permission bits. But because directories are interpreted in a special way by the filesystem, the permission bits have special meanings
You can use the opendir( ) and readdir( ) functions (or the ls command) to find out which files are in the directory.
You can add, rename, or remove entries in that directory.
You can stat the contents of a directory (e.g., you can determine the owners and the lengths of the files in the directory). You also need execute access to a directory to make that directory your current directory or to open files inside the directory (or in any of the directory's subdirectories).
If you want to prevent other users from reading the contents of your files, you have two choices:
You can set the permission of each file to 0600, so only you have read/write access.
You can put the files in a directory and set the permission of that directory to 0700, which prevents other users from accessing the files in the directory (or in any of the directory's subdirectories) unless there is a hard link to each file from somewhere else.
|For a directory, the set-groupID (SGID) flag means that all files created inside that directory will inherit the group of the directory. Without this flag, a file takes on the primary group of the user creating the file. This property is important to people trying to maintain a directory as group accessible. The subdirectories also inherit the parent directory attibutes.|
You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to any directory beneath (contained in) that directory.
If you do not have execute access to a directory, you cannot access the files within that directory, even if you own them.
If you have execute access to a directory but do not have read access, you cannot list the names of files in the directory (e.g., you cannot read the contents of the directory). However, if you have access to individual files, you can run programs in the directory or open files in it. Some sites use this technique to create secret files—files that users can access only if they know the files' full pathnames.
To unlink a file from a directory, you need to have write and execute access to that directory, but not to the file itself.
Remember that the directory itself contains only name and inode information. If you have read access to a directory but do not have execute access, you can display a short listing of the files in the directory (ls); however, you will not be able to find out anything about the files other than their names as all attributes are stored in the inode of the file.
Novice users often encounter irritating "Permission denied" message. And some of them quickly learn that using root or setting permissions to 777 resolve this problem ;-). That teach us important lesson that educating the users probably can help avoiding a lot of security problems. But Unix permissions while simple of the surface actually are not that simple and can create problems not only for naive users but for system administrators as well. We will not discuss what are alternative and limit yourself to the basic unix permission scheme here.
As we all know Unix files have three types of owners: user, group, and others (world). For each type of owner there are three
types of permissions: read (
r), write (
w), and execute (
x). Directories are actually a
special kind of files as as such have the same structure of permissions but their meaning is not identical and the directory permissions
affect the permissions on the files in this directory but not vise versa.
There also also three "special" permissions that are not bound to a particular owner (suid, sgid and sticky bit).
In most cases the root user is not a subject to any permissions restrictions.
How-To Hardening Systems, Users, Groups and Security
On other systems the group owner of su should be changed to wheel, or root on some systems, or security on AIX. Members of this group should be restricted to those who are given and authorized to use the root password. Su is left group executable but world execution rights are removed. This prevents anyone who is not authorized to use the root password, from using it under most circumstances, even if they learn the root password. Most server consoles are in secure areas where non technical staff do not have access or are very conspicuous. On systems that do not allow direct root access from remote locations, it not only takes two passwords to gain root privileges but they have to be the right two passwords. The first password is reduced from the entire user population to a very small population that hopefully pick good passwords.
The technique might be extended to other programs though none have quite the security implications of su. I would never set the SUID bit on a program that did not have it and then restrict the use of that program to wheel. Rather the members of wheel should su or sudo to access the program. Where the technique may make sense is if there are programs that are already SUID and it is believed that the functions provided by these programs are not needed by ordinary users. Presumably the system authors thought world execute access is not particularly harmful or the program would not be set up in such a way. Removing world access and changing the group owner to wheel restricts access to the program while keeping it convenient for wheel members. To make such programs secure, the SUID bit should be reset, forcing wheel members to su or sudo to use the command.
All directories have the same permissions structure as files (owner/group/world) with three permissions for each group. BTW that includes / (root) directory. Here is how to view them:
ls -ld /
note that you can see the number of 512-byte blocks used by the directory (the size of the directory)
Many Unix administrators do not suspect that classic ls -la command that is used to list "dotfiles" also produces the permissions of the current directory and its parent:
When a user creates a directory its permissions are determined by the current umask. It's owner corresponds to the effective UID of the account that create the directory, but its group depends on the directory permissions in which file is created. If sticky bit is set of the current directory then the group will be inherited from the current directory. Otherwise the primary group of the account will be used.
When user copies directory its ownership is changed to the user uid and the group is preserved only if the user is a member of this group.
This is "bolt on" addition to classic Unix permission model, which never was formally ratified but still is present in Red Hat. It is a "bot on" solution, badly engineered, very difficult to understand and contain numerous traps and pitfalls. That's probably why it was never ratified by Posix and exists only as draft.
Like VMS and Windows (which is derivative of VMS) this model is file centric: you can assign the set of rights to individual file or a group of files. Moreover if they exist, those permissions have higher priority and overwrite classic Unix permissions. One positive aspect is that it now allow to eliminate the limitation the in classic Unix permission model in which each group is atomic -- it can consists only of users, but not groups. Now you can assign arbitrary permission for particular user on individual file basis.
The main drawback of this model is that it is almost impossible to understand and it is not well integrated with classic Unix permissions (ls does not display them, but just indicates their presence). It smells "beta".
ACLs behaves differently for files and directories:
When you create a directory, you can simultaneously set default ACL entries for the owner, owner's group, others, and the ACL mask for this directory.
umaskto regular file operations (umask works only during the creation of the file). It defines the maximum permissions allowed for owner and groups that were granted the access rights to the file via ACL mechanism and overwrites all other settings.
There are two cases here
Consider this scenario: You are the administrator of a multi-user server. All of a sudden there is a new bug in the Pentium(tm) processor! As it happens, this bug causes the CPU to lock up entirely, requiring a cold reboot. This bug is also exploitable by any user regardless of privilege. All it necessitates is for the malevolent user to 1) get the source, 2) compile the exploit, and 3) execute the program.
You cannot prevent anyone from getting this exploit. It's out there. You could remove executable permissions from the compiler on your machine or remove the compiler entirely, but this does not stop the user from compiling the exploit elsewhere, and getting the binary on your machine somehow.
However, if you only allow binaries to be executed from a trusted path, you can block users from executing this exploit. A trusted path can be defined as one that is limited to root owned directories that are not group or world writable. /bin, /usr/bin, /usr/local/bin, are (under normal circumstances) considered trusted.
Any non-root users home directory is not trusted, nor is /tmp. Such configuration can be a major annoyance to users who like to execute code and scripts from their home directories! And it will make you extremely un-popular as far as these people are concerned. But at the same time for critical servers it will also let you sleep easier at night knowing that no unscrupulous persons will be executing malicious bits of code on your machine.
The implementation is very simple: before any call to exec is allowed to run, we open the inode of the directory that the executable lives in and check ownership and permissions. If the directory is not owned by root, or is writable by group or world, we consider it untrusted.
When a non-root user copies directory its ownership is changed to the user uid and the group is preserved only if the user is a member of this group.
User can change group only to those groups where this user is a member. If user copies the file then ownership of the file is changes to the user. Group is preserved (with -p option) if and only if the user is a member of troup.
What you can do with file is actually determined not only permissions of the file itself, but also permissions of the directory in which the file is located. Actually in Unix effective write attribute for the file is partially (delete operation) inherited from the corresponding attribute of the directory, for example:
ls -la /.profile
-rw-r--r-- 1 root wheel 658 Jul 26 23:14 /.profile
This looks counterintuitive, but that's how Unix operate: any writable by group or world directory in Unix permit file deletion renaming and creation by any member of the group or if it's world writable by the world (deletion can be blocked with sticky bit, but renaming and creation are not).
As such world writable directories are very dangerous and definitely represent a security risk.
Most Unix administrators that I know are pretty comfortable with octal permissions, but rarely use
chmod in symbolic
mode. The syntax for symbolic mode actually is simpler and more logical then octal mode:
who operator permission filename
who can be:
u= user (owner)
a= all, or ugo
operator can be:
+add this permission
-take away this permission
=make this permission equal to
and the permissions can be
that there is no capital
S; if you want to keep the execute bit when you set the SUID or SGID bits, use both
x. If you want to set the SUID bit, use
s with a who of
u; to set the SGID bit, use
s with a who of
g. To set the sticky bit, use
t with a who of
Let's try to change the foolowing file:
-rw-r--r-- 1 skeptic wheel 0 Aug 19 11:27 test
and want to end up with:
-rwsr-xr-x 1 skeptic wheel 0 Aug 19 11:27 test
so let's try this:
chmod -v a+sx test ls -la test-rwsr-sr-x 1 skeptic wheel 0 Aug 19 13:05 test
Close, but no cigar. Since we specified a who of
a (or everyone), we set both the SUID and SGID bits. Let's try again:
rm test touch test chmod u+s go+x testchmod: go+x: No such file or directory
We got a syntax error on that command because
chmod expects the who, operator, and permissions to be a string of characters
without any spaces. Whatever follows the space is interpreted as the name of the file whose permissions are being set. Let's try again:
chmod -v u+s,go+x test ls -la test-rwSr-xr-x 1 skeptic wheel 0 Aug 19 13:16 test
Almost there; we seem to have set the SUID bit and given everyone except the owner execute permission. One more try:
rm test touch test chmod u+sx,go+x test ls -la test-rwsr-xr-x 1 skeptic wheel 0 Aug 19 13:22 test
Success. You can see that it is a good idea to always doublecheck your permissions using
ls -la after using the
chmod command to make sure you actually set the permissions you intended.
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: March 12, 2019