SecContIOFS

Table of Contents

• Prepare
• Develop & Check
• tools
  • to check attrs from cmdline
  • to check FS internals
• SMACK
  • SMACK attributes
  • SMACK rules
  • SMACK glossary
  • SMACK toy-policy

Is a toy-vsf-wrapper to illustrate File IO interception importance for OS level virtualisation (i.e. containerization).

Prepare

1. clone SecContIOFS repository from GitHub

2. prepare environment (tests and checks were done on SMACK enabled Linux debian v4.9.30)

   1. setup bridge or set of dedicated phys network devices (per container)

      1. default: bridge + veth

   2. build and install kernel with SMACK support

sudo apt-get install build-essential fakeroot
sudo apt-get build-dep linux
apt-get source linux/stable
cd linux-4.9.30/
debian/rules debian/control
sudo apt-get install libncursesw5-dev
make nconfig

========= .config =============

--- Networking support
    Networking options  --->
        [*] NetLabel subsystem support
    Security options  --->
        [*] Simplified Mandatory Access Control Kernel Support
        [*]   Reporting on access granted by Smack rules (NEW)
        [*]   Packet marking using secmarks for netfilter (NEW)
        [*]   Treat delivering signals as an append operation (NEW)
        Default security module (Simplified Mandatory Access Control)  --->
            <X> Simplified Mandatory Access Control

================================

scripts/config --disable DEBUG_INFO
make clean
make deb-pkg -j4
...
dpkg -i ../*.deb

1. install LXC & LXCFS

   apt-get install lxc lxcfs

2. place base container rootfs at /srv/data/lxc-base/rootfs

3. prepare places for U & P containers /srv/data/cont-priv and /srv/data/cont-unpriv respectively

4. place configs

5. create mount points for U & P containers

   mkdir /srv/data/cont1 /srv/data/cont2

   1. build module

      cd <cloned-repo>/fs/seccontiofs
      make

   2. load module into the kernel

      insmod seccontiofs.ko

   3. check it’s available

      grep seccontiofs /proc/filesystems

   4. mount rootfs for your containers

      mount -t seccontiofs /path/to/basefs /path/to/contfs

   5. apply SMACK policies

Develop & Check

After reboot try to run containers.

Check all possibilities to break jails, fix and retry.

Note	current source tree contains only basic skeleton of the VFS Filter and requires developers to implement its parts according to their needs.

tools

to check attrs from cmdline

 # apt-get install acl
 # getfacl <file>

 # apt-get install attr
 # getfattr <file>

 # apt-get install xattr
 # xattr <file>

ls -Z to show the SMACK labels on files.

chsmack to show and sett all of the SMACK attributes on files.

cp --preserve=xattr to create a new file with the same content and SMACK attributes as an existing file.

id and id -Z to show the current process SMACK label.

ps -Z show information about processes, including their SMACK labels.

to check FS internals

SecContIOFS contains set of tools at check dir.

SMACK

Simplest way to set SMACK label on a file is:

attr -S -s SMACK64 -V "label" /path/to/a/file

or

chsmack -a label /path/to/a/file

SMACK attributes

The extended attributes that SMACK uses are:

SMACK64

Used to make access control decisions. In almost all cases the label given to a new filesystem object will be the label of the process that created it.

SMACK64EXEC

The SMACK label of a process that execs a program file with this attribute set will run with this attribute’s value.

SMACK64MMAP

Don’t allow the file to be mmapped by a process whose SMACK label does not allow all of the access permitted to a process with the label contained in this attribute. This is a very specific use case for shared libraries.

SMACK64TRANSMUTE

Can only have the value “TRUE”. If this attribute is present on a directory when an object is created in the directory and the SMACK rule that permitted the write access to the directory includes the transmute (“t”) mode the object gets the label of the directory instead of the label of the creating process. If the object being created is a directory the SMACK64TRANSMUTE attribute is set as well.

SMACK64IPIN

This attribute is only available on file descriptors for sockets. Use the SMACK label in this attribute for access control decisions on packets being delivered to this socket.

SMACK64IPOUT This attribute is only available on file descriptors for sockets. Use the SMACK label in this attribute for access control decisions on packets coming from this socket.

SMACK rules

Using the smackload utility it is possible to add access rules in /etc/smack/accesses. They take the form:

subjectlabel objectlabel accessspec

Where accessspec is a combination of the letters rwxatb which specify the kind of access permitted a subject with subjectlabel on an object with objectlabel.

If there is no rule no access is allowed.

SMACK glossary

The jargon used to talk about Smack will be familiar to those who have dealt with other MAC systems and shouldn’t be too difficult for the uninitiated to pick up. There are four terms that are used in a specific way and that are especially important:

Subject

A subject is an active entity on the computer system. On SMACK a subject is a task, which is in turn the basic unit of execution.

Object

An object is a passive entity on the computer system. On SMACK files of all types, IPC, and tasks can be objects.

Access

Any attempt by a subject to put information into or get information from an object is an access.

Label

Data that identifies the Mandatory Access Control characteristics of a subject or an object.

These definitions are consistent with the traditional use in the security community. There are also some terms from Linux that are likely to crop up:

Capability

A task that possesses a capability has permission to violate an aspect of the system security policy, as identified by the specific capability. A task that possesses one or more capabilities is a privileged task, whereas a task with no capabilities is an unprivileged task.

Privilege

A task that is allowed to violate the system security policy is said to have privilege. As of this writing a task can have privilege either by possessing capabilities or by having an effective user of root.

SMACK toy-policy

This sandbox is intended to cover the following case: two virtual systems at containers from a common rootfs with a fully controlled activity (capabilities, seccomp, acl, namespaces, IO), where running application are in a jail and fully managed by some kind of ControlApp. Host behavior depends on some external activity and thus changes containers mode and rules for applications. Cross-container access is strictly prohibited. Jail break should be impossible.

Basic (startup) policy

U1 _ rwa
_ U1 rwa
P1 _ rwa
_ P1 rwa
_ host rwax
host _ rwax