333.1 Discretionary Access Control

Topic 333: Access Control

Weight: 3

Description: Candidates should understand discretionary access control (DAC) and know how to implement it using access control lists (ACL). Additionally, candidates are required to understand and know how to use extended attributes.

Key Knowledge Areas:

  • Understand and manage file ownership and permissions, including SetUID and SetGID bits

  • Understand and manage access control lists

  • Understand and manage extended attributes and attribute classes

Partial list of the used files, terms and utilities:

  • getfacl

  • setfacl

  • getfattr

  • setfattr

basic System Permissions (DAC review)

First lets have a quick review

chmod

The command you use to change the permissions on files is called chmod , which stands for “change mode". There are to ways to tell this command what you want to do:

  • using short codes

  • using ocatl codes

1- using short codes: That is easier way. 

chmod [reference][operator][mode] file...

reference can be

  • u as user (file's owner)

  • g as group (users who are members of the file's group)

  • o as others (users who are not the file's owner / members of the file's group)

  • a as all (All three of the above, same as ugo)

Operator can be

  • + Adds the specified modes to the specified classes

  • - Removes the specified modes from the specified classes

  • = The modes specified are to be made the exact modes for the specified classes

obviously modes might be

  • r :Permission to read the file

  • w :Permission to write (or delete) the file.

  • x : Permission to execute the file, or, in the case of a directory, search it.

Note1: If we want to set different permissions for user, group, or other, we can separate different expressions by commas —for example, ug=rwx,o=rx

Note2: using a as ugo with = operator to set exact mode easier

2- using ocatl codes : So far we have used symbols (ugoa and rwx) to specify permissions. we can also set permissions using octal numbers instead of symbols.

For using octal codes with chmod we have to create an octal string, and that's is nothing more than a simple sum of numbers:

Note: To change permissions recursively on directories and files use -R option

suid , guid

The Linux permissions model has two special access modes called suid (set user id) and sgid (set group id). When an executable program has the suid access modes set, it will run as if it had been started by the file’s owner, rather than by the user who really started it. Similarly, with the sgid access modes set, the program will run as if the initiating user belonged to the file’s group rather than to his own group.

Directories and sgid

When a directory has the sgid mode enabled, any files or directories created in it will inherit the group ID of the directory. This is particularly useful for directory trees that are used by a group of people working on the same project.

sticky bit

We have just seen how anyone with write permission to a directory can delete files in it. This might be acceptable for a group project, but is not desirable for globally shared file space such as the /tmp directory. Fortunately, there is a solution. That is called the sticky bit.

If set stickybit for a directory, it permits only the owning user or the superuser (root) to delete or unlink a file.

How suid, guid and stickybit are implemented?

As there is no more room for setting Access modes, execution character is used. "s" letter is used for both suid and guid but "t" letter is for stickybit. Again we use +/- for adding and removing permissions.

As you have probably noticed, if the file or directory is already executable s and t would be displayed after setting access modes.

But if the file or directory hasn't been executable before setting access mode, S and T would be appear.

Setting Access Modes via octal codes:

We can also use octal codes to set suid, guid and stickybit:

this part was from my LPIC1 book, visit: https://borosan.gitbook.io/lpic1-exam-guide/1045-manage-file-permissions-and-ownership#chmod

chown

The root user can change the ownership of a file using the chown command.We can use user name or user ID.

chown [OPTION]… [OWNER][:[GROUP]] FILE…

The file’s group may be changed at the same time by adding a colon and a group name or ID right after the user name or ID.

note1: If only a colon is given, then the user’s default group is used

note2: the -R option will apply the change recursively and -c Reports when a file change is made. We can also use other file ownership via --referenece switch.

review my LPIC1 book: https://borosan.gitbook.io/lpic1-exam-guide/1045-manage-file-permissions-and-ownership#chown

Extended Attributes

There is a mechanism for adding additional data to a file or directory in a filesystem. This is called Extended File Attributes (abbreviated xattr). In Linux, many file systems support it such as the following: ext2, ext3, ext4, jfs, xfs, reiserfs, btrfs,... .

Many modern linux Filesystems support Extended Attributes if the libattr feature is enabled in the kernel configuration.

Extended file attributes are key-value pairs that can be set programmatically by the file system, by other middleware such as the Data Management API, by the operating system, or by users.

The name of an extended attribute consists of a namespace name followed by a dot followed by an attribute name, as in the following extended attribute names:

user.swift.metadata

system.posix_acl_access

The public namespaces are:

  • user: A general purpose namespace with no restrictions regarding naming or contents.

If you have write permission on the file, then you can set an extended attribute. If you give someone else read access to the file, they can read the extended attributes. If another user can write to the file, they can read, write, or delete any of the user extended attributes.

  • trusted: Attributes in this class are used to implement mechanisms in user space which keep information in extended attributes to which ordinary processes should not have access.

To use the trusted extended attributes the application or user has to have CAP_SYS_ADMIN capability (e.g., the superuser).

  • security: The security namespace is used by SELinux. An example of a name in this namespace would be something like security.selinux.

  • system: The system namespace is used primarily by the kernel for access control lists (ACLs)

The system namespace can only be set by root.

Xattr

Lets take a look at attribute commands family available in attr package.

getfattr

The getfattr , For each file in a provided path, getfattr displays the file name, and the set of extended attribute names (and optionally values) which are associated with that file

Notable options:

  • -n <name> , --name=<name> : returns the named attributes for a given path

  • -m <pattern> , --match=<pattern> :returns attributes with attributes matching the provided pattern

example:

[root@rocky8 sandbox]# touch file1
[root@rocky8 sandbox]# getfattr file1
[root@rocky8 sandbox]# echo $?
0

getfattr doesn't show error if any attribute is not specified.

setfattr

The setfattr command associates a new value with an extended attribute name for each specified file.

Notable options:

  • -n <name> , --name=<name> : returns the named attributes for a given path

  • -v <value> , --value=<value> : the new value to assign to a given attribute

  • -x <name>, --remove=<name> : remove an attribute entirely

example:

[root@rocky8 sandbox]# setfattr -n user.comment -v "comment" file1
[root@rocky8 sandbox]# getfattr file1
# file: file1
user.comment

delete:

[root@rocky8 sandbox]# setfattr -x user.comment file1
[root@rocky8 sandbox]# getfattr file1
[root@rocky8 sandbox]#

try man getfattr and man setfattr for more information.

Using ACLs

Standard rights and extended rights are interesting features but only apply to a single user or a single group. How to define specific permissions, even different, for other users or groups than the owners? ACLs offer an answer to this question.

Note: “ACLs are not natively enabled on Ubuntu but the kernel supports them. The apt://acl package should normally be already installed.” https://help.ubuntu.com/community/FilePermissionsACLs.

Linux ACLs are natively supported on Red Hat based distributions.

ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing the base ownership and permissions. They let us "tack on" access for other users or groups.

There are four entry tags that ACL permissions may be assigned to:

  • user: The file owner or a specified user; may be abbreviated u

  • group: The group owner or a specified group; may be abbreviated g

  • mask: An entry that specifies that maximum access which can be granted by any ACL entry EXCEPT the user entry for the file owner; may be abbreviated as m

  • other: An entry that specifies access granted to any process that does not match any user or group ACL entries; may be abbreviated o

Read, Write, and Execute permissions may be assigned to any specified identifier

ACLS are supplied in the following format: entry_tag:identifier:object_permissions

Examples:

The user john has read and write access: u:john:rw-

The group staff has read access: g:staff:r--

Other access is no access: o::---

Order of permission application:

  • The file owner permission applies above all other entries

  • User permissions override group permissions up to the level allowed by a set ACL mask

  • Group permissions up to the level allowed by the ACL mask

  • Other ACL permissions apply for anything not matched by a user or group

Lets see how to manage acls:

getfacl

getfacl gets file access control lists For each file. getfacl displays the file name, owner, the group, and the Access Control List (ACL) . If a directory has a default ACL, getfacl also displays the default ACL( Non-directories cannot have default ACLs).

[root@rocky8 sandbox]# touch newfile
[root@rocky8 sandbox]# ll
total 0
-rw-r--r--. 1 root root 0 Sep  8 00:27 newfile
[root@rocky8 sandbox]# getfacl newfile
# file: newfile
# owner: root
# group: root
user::rw-
group::r--
other::r--

We can see that right now, there are no ACLs on this file because the only permissions listed are for the user, group, and other. In this case, that's to be expected, because I just created this file in the lab and haven't done anything other than assigning ownership.

If getfacl is used on a file system that does not support ACLs, getfacl displays the access permissions defined by the traditional file mode permission bits.

setfacl

The syntax for setting an ACL looks like this:

setfacl [option] [action/specification] file

  • The 'action' would be -m (modify) or -x (remove)

  • the specification would be the user(u) or group(g) followed by the permissions we want to set.

1) To add permission for user
setfacl -m "u:user:permissions" /path/to/file

2) To add permissions for a group
setfacl -m "g:group:permissions" /path/to/file

example: 

[root@rocky8 sandbox]# useradd mona
[root@rocky8 sandbox]# setfacl -m u:mona:r newfile
[root@rocky8 sandbox]# ll
total 0
-rw-r--r--+ 1 root root 0 Sep  8 00:27 newfile
[root@rocky8 sandbox]# getfacl newfile
# file: newfile
# owner: root
# group: root
user::rw-
user:mona:r--
group::r--
mask::r--
other::r--

remove:

[root@rocky8 sandbox]# setfacl -x u:mona newfile
[root@rocky8 sandbox]# ll
total 0
-rw-r--r--+ 1 root root 0 Sep  8 00:27 newfile
[root@rocky8 sandbox]# getfacl newfile
# file: newfile
# owner: root
# group: root
user::rw-
group::r--
mask::r--
other::r--

To remove all entries setfacl -b path/to/file

The ACL’s mask setting

The mask setting is set to the maximum allowed setting for all users. This “effectively” override special permissions.

The mask setting will automatically update again indirectly when you modify permissions using either the chmod or setfacl command. But you can also directly change the mask setting as well.E.g. if you wan to set the mask to “r-x”, then you do:

[root@rocky8 sandbox]# setfacl -m m::rx newfile
[root@rocky8 sandbox]# getfacl newfile
# file: newfile
# owner: root
# group: root
user::rw-
group::r--
mask::r-x
other::r--

Notice that we have “::” since it is empty as the mask setting is not something particular to a user or group.

other examples:

A Directory with a Default ACL

Directories can be equipped with a special kind of ACL -- a default ACL. The default ACL defines the access permissions all objects under this directory inherit when they are created. A default ACL affects subdirectories as well as files.

Effects of a Default ACL

There are two different ways in which the permissions of a directory's default ACL are handed down to the files and subdirectories in it:

  • A subdirectory inherits the default ACL of the parent directory both as its own default ACL and as an access ACL.

  • A file inherits the default ACL as its own access ACL.

All system calls that create file system objects use a mode parameter that defines the access permissions for the newly created file system object:

  • If the parent directory does not have a default ACL, the permission bits as defined by the umask are subtracted from the permissions as passed by the mode parameter, with the result being assigned to the new object.

  • If a default ACL exists for the parent directory, the permission bits assigned to the new object correspond to the overlapping portion of the permissions of the mode parameter and those that are defined in the default ACL. The umask is disregarded.

Application of Default ACLs

The following three examples show the main operations for directories and default ACLs:

  1. Creating a default ACL for an existing directory

  2. Creating a subdirectory in a directory with default ACL

  3. Creating a file in a directory with default ACL

Let's do it:

  1. Add a default ACL to the existing directory mydir:

setfacl -d -m group:djungle:r-x mydir

The option -d of the setfacl command prompts setfacl to perform the following modifications (option -m) in the default ACL.

Take a closer look at the result of this command:

$ getfacl mydir

# file: mydir
# owner: tux
# group: project3

user::rwx
user:jane:rwx
group::r-x
group:djungle:rwx
mask::rwx
other::---

default:user::rwx
default:group::r-x
default:group:djungle:r-x
default:mask::r-x
default:other::---

getfacl returns both the access ACL and the default ACL. The default ACL is formed by all lines that start with default. Although you merely executed the setfacl command with an entry for the djungle group for the default ACL, setfacl automatically copied all other entries from the access ACL to create a valid default ACL. Default ACLs do not have an immediate effect on access permissions. They only come into play when file system objects are created. These new objects inherit permissions only from the default ACL of their parent directory.

2. In the next example, use mkdir to create a subdirectory in mydir, which will ``inherit'' the default ACL.

$ mkdir mydir/mysubdir

$ getfacl mydir/mysubdir

# file: mydir/mysubdir
# owner: tux
# group: project3

user::rwx
group::r-x
group:djungle:r-x
mask::r-x
other::---

default:user::rwx
default:group::r-x
default:group:djungle:r-x
default:mask::r-x
default:other::---

As expected, the newly-created subdirectory mysubdir has the permissions from the default ACL of the parent directory. The access ACL of mysubdir is an exact reflection of the default ACL of mydir, just as the default ACL that this directory will hand down to its subordinate objects.

3. Use touch to create a file in the mydir directory:

$ touch mydir/myfile

$ ls -l mydir/myfile

-rw-r-----+ ... tux project3 ... mydir/myfile


$ getfacl mydir/myfile

# file: mydir/myfile
# owner: tux
# group: project3

user::rw-
group::r-x          # effective:r--
group:djungle:r-x   # effective:r--
mask::r--
other::---

Important in this example: touch passes on mode with the value 0666, which means that new files are created with read and write permissions for all user classes, provided no other restrictions exist in umask or in the default ACL.

If effect, this means that all access permissions not contained in the mode value are removed from the respective ACL entries. Although no permissions were removed from the ACL entry of the group class, the mask entry was modified to mask permissions not set via mode.

This approach ensures the smooth interaction of applications, such as compilers, with ACLs. You can create files with restricted access permissions and subsequently mark them as executable. The mask mechanism makes sure that the respective users and groups are assigned the permissions they are granted in the default ACL.

that's all.

.

.

.

resources:

https://www.geeksforgeeks.org/chmod-command-linux/

https://www.redhat.com/sysadmin/suid-sgid-sticky-bit

https://www.linuxtoday.com/blog/linux-extended-file-attributes/

https://www.ibm.com/docs/en/spectrum-scale/5.0.5?topic=gpfs-planning-extended-attributes

https://www.admin-magazine.com/HPC/Articles/Extended-File-Attributes

https://linux.goffinet.org/administration/securite-locale/access-control-lists-acls-linux/

https://www.redhat.com/sysadmin/linux-access-control-lists

https://www.geeksforgeeks.org/access-control-listsacl-linux/

https://codingbee.net/rhcsa/rhcsa-the-acls-mask-setting

https://unix.stackexchange.com/questions/147499/what-relationships-tie-acl-mask-and-standard-group-permission-on-a-file

https://mirror.apps.cam.ac.uk/pub/doc/suse/suse9.0/adminguide-9.0/node27.html#:~:text=The%20default%20ACL%20defines%20the,subdirectories%20as%20well%20as%20files.

.

Previous332.3 Resource ControlNext333.2 Mandatory Access Control

Last updated