Is a toy-vsf-wrapper to illustrate File IO interception importance for OS level virtualisation (i.e. containerization).
-
clone SecContIOFS repository from GitHub
-
prepare environment (tests and checks were done on
SMACK enabled Linux debian v4.9.30-
setup bridge or set of dedicated
physnetwork devices (per container)-
default: bridge + veth
-
-
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-
install LXC & LXCFS
apt-get install lxc lxcfs
-
place base container rootfs at
/srv/data/lxc-base/rootfs -
prepare places for U & P containers
/srv/data/cont-priv/srv/data/cont-unpriv -
place configs
-
create mount points for U & P containers
mkdir /srv/data/cont1 /srv/data/cont2
-
build module
cd <cloned-repo>/fs/seccontiofs make
-
load module into the kernel
insmod seccontiofs.ko
-
check it’s available
grep seccontiofs /proc/filesystems
-
mount rootfs for your containers
mount -t seccontiofs /path/to/basefs /path/to/contfs
-
apply SMACK policies
-
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. |
# 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.
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
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.
Using the smackload utility it is possible to add access rules in /etc/smack/accesses. They take the form:
subjectlabel objectlabel accessspec
Where accessspecrwxatbsubjectlabelobjectlabel
If there is no rule no access is allowed.
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.
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.
U1 _ rwa
_ U1 rwa
P1 _ rwa
_ P1 rwa
_ host rwax
host _ rwax