Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Introduction to Unix permissions model

Understanding file permissions on Unix

News Access Control in Operating Systems Recommended Links SUID/SGID attributes Sticky attribute (sticky bit) in Unix Setgid bit in directories umask
World writable files problem SUID/SGID Checkers File Permissions Hardening Groups administration Admin Horror Stories Humor Etc

Introduction

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
1 001 --x
2 010 -w-
3 011 -wx
4 100 r--
5 101 r-e
6 110 rw-
7 111 rwx

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.

Disabling Unix permission model

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.

Unix file permission structure

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.

Setting file permission using symbolic notation

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

[user-class-letters] operator permission-symbols

Multiple maskExpressions are separated by commas.

A space terminates the maskExpression (s).

Letter Class Description
u user the owner
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
Operator Effect 
+ 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.
Symbol Name Description
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

For example:

chmod u-w ~.bash_profile

Groups in Unix are atomic but you can use metagroups by writing a compiler script

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.

Special users

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.

Special groups: wheel and system groups

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.

SUID vs SGID vs Sticky Bit

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). 

  1. Owner  (The file's owner) You can specify read, write execute permission and one additional attribute for files:
  2. Group (Users who are in the file's group) You can specify read, write execute permission and one additional attribute for directories:
  3. Other  Everybody else on the system ( except the superuser, owner and members of the group assigned to the file ). 

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:

% mkdir home/groups/perlsctipts
% 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.

Inheritance of permissions, umask

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
umask  command
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:

umask u-w,g=r,o+r

This would set the mask so that it would:

  1. prohibit the write permission from being set for the user, while leaving the rest of the flags unchanged;
  2. allow the read permission to be enabled for the group, while prohibiting write and execute permission for the group;
  3. allow the read permission to be enabled for others, while leaving the rest of the other flags unchanged.

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.

 

Every user on a Unix system has a unique username, and is a member of at least one group (the primary group for that user). The primary group is defined in /etc/passwd. A user can also be a member of one or more other groups. The auxiliary group information is held in the file /etc/group. Only the root user can create new groups or add/delete group members.

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.

User private groups

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. 

File permissions do not apply to symbolic links

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.

Interpretation of ls -l listing

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:

-rw-------
drwxr-xr-x

The first character of the file's mode field in ls listing indicates the type of file:

Contents Meaning
- Plain file
d Directory
c Character device (tty or printer)
b Block device (usually disk or CD-ROM)
l Symbolic link
s Socket
= 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.

The order of interpretation of permissions

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.

Directory permissions

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

Contents Permission Meaning
r Read You can use the opendir( ) and readdir( ) functions (or the ls command) to find out which files are in the directory.
w Write You can add, rename, or remove entries in that directory.
x Execute 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:

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.

Notes:

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.

How ACL permissions are bolted on classics Unix permission model

Posix ACL extend the concept of the group, adding into the mix Windows permission model

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:

The concept of trusted path

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.

Ownership issues on directories

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.

Symbolic mode of chmod

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

where who can be:

and operator can be:

and the permissions can be r, w, x, s, t, and X. Note that there is no capital S; if you want to keep the execute bit when you set the SUID or SGID bits, use both s and 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 o.

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 test

 chmod: 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.

See also



Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow 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-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 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 to buy a cup of coffee for authors of this site

Disclaimer:

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

Last modified: March 12, 2019