ACL

By default, Linux permissions only allow a single user and single group of a given directory/file. We can see this text file is owned by Joe and belongs to the "study" group.

ls -l test.txt 
-rw-r----- 1 joe study 8 Nov 30 19:33 test.txt

If we wanted more flexible permissions, such as a user that is not Joe nor part of the study group to be able to read and write to the file, we can use Access Control Lists (ACL). These are great for giving multiple groups access to a file or directory, or giving a specific user access even though they are not part of the file's group.

getfacl and setfacl are our two go-to commands (the f in the commands are"file"). Use the former to view the current permissions of a file. Here we have the default permission setup of a single user and group.

getfacl test.txt 
# file: test.txt
# owner: joe
# group: study
user::rw-
group::r--
other::---

Now lets add the work group by modifying -m the file and check it afterwords.

setfacl -m g:work:rw test.txt 
getfacl test.txt 
# file: test.txt
# owner: joe
# group: study
user::rw-
group::r--
group:work:rw-
mask::rw-
other::---

Now not only is the work group added for read and write permissions, but this created a mask. This is the maximum effective permissions for any entry in the ACL.

Attributes

Common permission attributes include append-only and immutability. Append-only prevents modifying existing content in a file, but only appending. Immutable files/directories cannot be written, appended, or deleted, even by root.

# change attribute to immutable
chattr -i [file]
# change attribute to append-only
chattr -a [file]

To list attributes of files in current directory, or point to a file/directory, use lsattr.

To check whether a file has either ACL permission set, attributes assigned, or both, look for the plus at the end of the permissions with ls -l.

#         v
-rw-rw----+  1 joe study     8 Nov 30 19:33 test.txt

Special Permissions

Set user ID (SUID)

When a program is ran with SUID, it executes with the permissions of whoever owns the file. In the case of umount, if a normal user were to execute this command, they would in fact run it as if they were root. This is generally for programs that require system access that you still want users to run.

#SUID bit set
   v
-rwsr-xr-x 1 root root       35192 Feb 20  2022 umount

Note if the file owner does not have execute permissions, there would be an uppercase S .

Another common example of SUID is the passwd command. Any user should be able to change their password and this is possible by executing the file as if they were root.

ls -l /bin/passwd
-rwsr-xr-x 1 root root 59976 Nov 24  2022 /bin/passwd

Adding this permission to a file is as follows.

chmod u+s <filename>

Set group ID (SGID)

SGID does the same thing but for running a program with permissions of the group. Here we can see the group of executable file ssh-agent is _ssg. When a user is running this program, they will act as a member of the file's group.

#SGID bit set
      v
-rwxr-sr-x 1 root _ssh      293304 Aug 24 08:40 ssh-agent
 ```
 SGID has a different function on directories. If set, any file created within that directory will inherit the group ownership of the parent directory group.

For example, this directory has an owner of bill and group of study. I can add SGID with the following. Note the before and after in the executable portion of the group permissions.

Before

drwxrwxr-x 2 bill study 4096 Dec 3 12:24 dir

chmod g+s sgid

After

drwxrwsr-x 2 bill study 4096 Dec 3 12:25 dir


`file1` was created by joe before adding the SGID. After it was set `file2` was created inheriting the study group from it's parent directory.

ls -l dir total 0 -rw-rw-r-- 1 joe joe 0 Dec 3 12:25 file1 -rw-rw-r-- 1 joe study 0 Dec 3 12:26 file2

##### Sticky bit
Folders with this activated cannot have files within them deleted or renamed by other users. This is commonly used on directories like `/tmp` to prevent users from deleting each other's files.

tmp folder has sticky bit set on by default

drwxrwxrwt 17 root root 4096 Dec 3 11:44 tmp

Use the following either in symbolic or numeric mode to add this restriction.

chmod +t dir

OR

chmod 1777 dir

Though it is possible to add sticky bit to a file, it currently has no function in modern Linux systems.

So what to remember about each 3 of these permissions is that SUID is for executable files only, SGID works on both files and directories, and sticky bit only works on directories.

#### Apparmor
Apparmor is a Linux kernel security module found in Debian based and Ubuntu systems. It provides Mandatory Access Control (MAC) to restrict programs, applications, and scripts capabilities with per-program profiles. It is considerably easier than SELinux setup and maintain. Unlike SELinux, which is based on applying labels to files based on their inodes, AppArmor works with file paths.

`aa-status` will display profiles of programs either in enforce mode, which will log and block access, and complain mode, which will only log. You can view these logs in `/var/log/syslog`.

Installing `apparmor-utils` includes essential commands such as those needed to move profiles to enforce or complain mode, and to generate profiles.

In the `/etc/apparmor.d` directory, you will find the profiles on your system as seen with `aa-status`. To create a profile with an easy template, use `aa-easyprof`, or `aa-genprof` to create your own.

To restrict the scope of access of the `ss` program, I can create a profile and place it in the apparmor directory as follows. Next I will enforce it.

❯ sudo aa-easyprof /usr/bin/ss > usr.bin.ss ❯ sudo mv usr.bin.ss /etc/apparmor.d/ ❯ sudo aa-enforce /etc/apparmor.d/usr.bin.ss

At first, the program will essentially be disabled until you explicitly define it's permissions. 

When I try to run `ss`, it is denied permission. These logs can then be found in `var/log/syslog`.

❯ ss Cannot open netlink socket: Permission denied Cannot open netlink socket: Permission denied Cannot open netlink socket: Permission denied ❯ tail -1 /var/log/syslog Dec 9 15:42:56 x230-2 kernel: [15915.826222] audit: type=1400 audit(1702158176.819:103): apparmor="DENIED" operation="create" profile="/usr/bin/ss" pid=16843 comm="ss" family="netlink" sock_type="raw" protocol=4 requested_mask="create" denied_mask="create"

`aa-logprof` is an interactive tools that reads `var/log/syslog` for Apparmor events and will generate a list of suggested profile changes that the user can choose from to update security profiles. For example, if I recently ran `ss` when after I restricted it, it would prompt me to adjust permissions.

❯ aa-logprof Updating AppArmor profiles in /etc/apparmor.d. Reading log entries from /var/log/syslog. Complain-mode changes:

Profile: /usr/bin/ss Network Family: netlink Socket Type: raw

[1 - include ] 2 - network netlink raw, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish

...

(S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t Writing updated profile for /usr/bin/ss.


After I have allowed access to multiple processes and saved changes to the profile. I can see the change in `usr.bin.ss`. The default `aa-easyprof` template it started with basically allows nothing, then afterwords we can see the what we allowed from `aa-logprof`.

Before `aa-logprof` (default `aa-easyprof`, nothing)

❯ cat /etc/apparmor.d/usr.bin.ss

vim:syntax=apparmor

AppArmor policy for ss

###AUTHOR

###COPYRIGHT

###COMMENT

include

No template variables specified

/usr/bin/ss { #include

# No abstractions specified # No policy groups specified # No read paths specified # No write paths specified }

After allowing access to multiple processes using `aa-logprof`

❯ cat /etc/apparmor.d/usr.bin.ss

Last Modified: Sat Dec 9 17:21:36 2023

include

vim:syntax=apparmor

AppArmor policy for ss

###AUTHOR

###COPYRIGHT

###COMMENT

No template variables specified

/usr/bin/ss { include include

/proc//net/raw r, /proc//net/udp r, /proc/*/net/unix r, }

#### SELinux
Security Enhanced Linux is a Mandatory Access Control (MAC) system built into the upstream Linux kernel itself. It was originally developed by the NSA and Red Hat as a series of security patches using Linux Security Modules (LSM).  

Two most important concepts in SELinux are Labeling and Type Enforcement.

Files, directories, ports, etc. are all labelled with a SELinux context. Files and directories' labels are stored as extended attributes on the filesystem. Processes and port's labels are managed by the kernel.

Labels are in this format: 
- user:role:**type**:level(optional)

Use the `-Z` flag to create files and directories with SELinux security context, or `ls` to print security context.

cp -Z mkdir -Z ls -Z

Use `chcon` and `restorecon` to change context of a file. Note changes with chcon do not survive a filesystem relabel, often triggered with `/.autorelabel` at boot time.

File's contexts are set when they are created based on their parent directories context (with some exceptions). File context and label's refer to the same thing.

Let's say some file is not working and you suspect it is the context after inspecting it with `ls -Z`. If you have a known good file you can reference it's context and point it at the file to copy it's context.

chcon --reference known-good.txt broken.txt ```

You can also restore a file or directory to the default context using restorecon.

To change the default setting, i.e persistent changes use semanage fcontext. Then run resorecon to apply the changes or run an autorelabel.

DAC & MAC - Discretionary vs Mandatory Access Control

Traditional Unix/Linux systems were discretionary. These have simple owner, group and other permissions. A user has the ability (discretion) to change permissions on their own files and chmod +rwx his own home directory and nothing will stop them, and then nothing will stop other users or processes from accessing that user's directory. On top of this Discretionary Access Control gives the root user omnipotent powers.

On Mandatory Access Control systems, there is a policy which is administratively set and fixed. Even if you change the DAC settings on your home directory, if there is a policy in place which prevents another user or process from accessing it, you're generally safe.

These policies can be very fine grained. Policies can be set to determine access between: - Users - Files - Directories - Memory - Sockets - tcp/udp ports - etc.

SELinux and Apparmor Comparison

Selinux operates at the system level, while Apparmor works at the applications level.
Apparmor identifies filesystem objects by filepath as opposed to Selinux which identifies them by inode.
Selinux is used by RHEL(Red Hat), SLES(SUSE), and Android, while Apparmor is used by Debian and Ubuntu.

Application Level Apparmor - Deny Everything Selinux - Allow Everything System Level Apparmor - Allow Everything Selinux - Deny Everything

Comparison of SELinux and AppArmor

Feature	SELinux	AppArmor
Original Sponsor	DoD/NSA (USA)	DoD/DARPA (USA)
Approach	Deny everything system level	Deny everything application level
Integration in Linux	LSM Module + Userland	LSM Module + Userland
Performance Impact	<5%	0-2%
Restriction	MAC, RBAC, MLS, Network Labeling	MAC, RBAC, (MLS)
Confinement	Indirect, via "Labels"	Direct, Path based
Profiles/Policies	"Program" needs to be compiled	Simple text files, Unix style
Auditing / Human	SELinux policies are hard to read and to audit	AppArmor profiles are easy to audit
Availability in Distros	CentOS, RHEL, SUSE Linux Enterprise	Ubuntu, openSUSE, SUSE Linux Enterprise
Primary Adoption	US/Canada	Worldwide
Notes	SUSE Linux Enterprise - Support for software stack, no policy included in SLES. Preconfigured part of SLE Micro 5.	Support for software stack and AppArmor profiles. Will be used for CCC for SLE 15.
Courtesy SUSECON
#### Additional Learning
SUSE Conference Overview of SELinux and AppArmor Presentation
Red Hat Summit Security-Enhanced Linux for mere mortals Presentation
Very in depth interview with Selinux/NSA Engineer Interview
Red Hat Selinux Documentation