LPIC3 Exam Guide
Search…
⌃K

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 grou)
  • 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 rxw) 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:
Symbolic
Note
Octal
rwx
4+2+1
7
rw-
4+2
6
r-x
4+1
5
r--
4
4
-wx
2+1
3
-w-
2
2
--x
1
1
---
0
0
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.
Access mode
on file
on directory
SUID
executes with permissions of file owner
nothing
GUID
executes with the permissions of group
new files have group membership of directory
Sticky Bit
nothing
only owner can delete files

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:
Access Mode
Octal
SUID
4000
GUID
2000
Sticky Bit
1000

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.

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: The user namespace attributes are protected by the normal Unix user permission settings on the file. 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: 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) and can only be set by root.

Xattr

Lets take a look at attribute commands family available in attr package.
Getting xattrs:
getfattr
  • -n <name>, --name=<name>: Dump the value of the named extended attribute.
  • -m <pattern>, --match=<pattern> :Only include attributes with names matching the regular expression pattern. The default value for pattern is "^user\.", which includes all the attributes in the user namespace. Specify "-" for including all attributes. Refer to attr(5) for a more detailed discussion of namespaces.
Setting xattrs:
setfattr
-n <name>, --name=<name>: Specifies the name of the extended attribute to set.
-v <value>, --value=<value>: Specifies the new value of the extended attribute. There are three methods available for encoding the value. If the given string is enclosed in double quotes, the inner string is treated as text. In that case, backslashes and double quotes have special meanings and need to be escaped by a preceding backslash. Any control characters can be encoded as a backslash followed by three digits as its ASCII code in octal. If the given string begins with 0x or 0X, it expresses a hexadecimal number. If the given string begins with 0s or 0S, base64 encoding is expected. Also see the --encoding option of getfattr(1).
-x <name>, --remove=<name>: Remove the named extended attribute entirely.
example:
[[email protected] sandbox]# touch file1
[[email protected] sandbox]# getfattr file1
[[email protected] sandbox]# echo $?
0
getfattr doesn't show error if any attribute is not specified.
[[email protected] sandbox]# setfattr -n user.comment -v "comment" file1
[[email protected] sandbox]# getfattr file1
# file: file1
user.comment
delete:
[[email protected] sandbox]# setfattr -x user.comment file1
[[email protected] sandbox]# getfattr file1
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.

getfacl

We can view the current ACL using the getfacl command:
[[email protected] sandbox]# touch newfile
[[email protected] sandbox]# ll
total 0
-rw-r--r--. 1 root root 0 Sep 8 00:27 newfile
[[email protected] 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.

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:
[[email protected] sandbox]# useradd mona
[[email protected] sandbox]# setfacl -m u:mona:r newfile
[[email protected] sandbox]# ll
total 0
-rw-r--r--+ 1 root root 0 Sep 8 00:27 newfile
[[email protected] sandbox]# getfacl newfile
# file: newfile
# owner: root
# group: root
user::rw-
user:mona:r--
group::r--
mask::r--
other::r--
remove:
[[email protected] sandbox]# setfacl -x u:mona newfile
[[email protected] sandbox]# ll
total 0
-rw-r--r--+ 1 root root 0 Sep 8 00:27 newfile
[[email protected] 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:
[[email protected] sandbox]# setfacl -m m::rx newfile
[[email protected] 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.
that's all.
.
.
.
resources:
.