Security/A computer-aided SMACK
This is a proposal for a computer-aided method for designing SMACK security of a whole platform.
We would like to have a very simple security model based on the onion rings model mixed or not with functionnal access control.
The security rings (layers) of the onion could be the 6 below, from the strongest (the one that can do almost anything but that can't be entered easyly) to the leakest (the one that have many restriction but that is entered by default):
- CORE: the kernel, its config, the packaging and update system;
- SYSTEM: the components of the linux system;
- PLATFORM: the components of tizen platform;
- TRUSTED: the components that are certificated and trusted;
- UNTRUSTED: the untrusted components;
- USER: the user components.
The functionnal access control can be used to secure native application. The idea is to restrict access of ressources. The following few groups could be used:
- STORAGE: access to the storage (read/write)
- CALLING: access to the calling facilities (dial, sms, mms, ...)
- NETWORK: access to the networks
- POSITION: access to the position of the device (gps, ...)
- SYSTEMINFO: access to system's data (read)
- USERDATA: access to the user data (contacts, ...)
- SOCIAL: access to social networking sites
Method of design
We want to design the security at the global system level, taking into account all the RPMs currently known. The goal is to know the set of smack rules to be used to put the security SMACK labels on any file that can be installed(*). The SMACK labels that have to be known are at least: SMACK64, SMACK64EXEC, SMACK64MMAP, SMACK64TRANSMUTE.
The count of RPM provided and installable can be big (for a typical image, including all: source, debug, docs, ..., its about 5800 RPMs). It means that we need a kind of help: we will use a computer-aided design solution. Indirectly, the use of a computer-aided solution will improve the formal modelisation of the security.
The software used will help to the stages:
- design the security rules;
- test and experiment the design;
- produce the manifest files for packaging;
- audit manifests of RPMs.
During the stages 1 and 2, the software applies the rules to the filesystem. At first we will start with the following kind of rules (new rules will be added if need).
- set label(s) of an item (file, link or directory);
- set label(s) of the items (file, link or directory) of a directory;
- set label(s) of the items (file, link or directory) of a directory and recursively to the items of its subdirectories;
- set label(s) of the items (file, link or directory) of a package;
- set label(s) of the items (file, link or directory) of a group of packages;
For stages 3 and 4, the software will deal with the manifest files of the RPMs, helping to define or check it. See Security/Application_installation_and_Manifest.
Specification of the software
The software manages a set of security rules that it applies to a set of RPM packages and the corresponding filesystem. To help it will enable to show lakes of design and relationship between packages.
The software will handle the following objects:
- The set of security rules (see above).
- The packages. It contains files, links, directories, modes, scripts.
- The filesystem of the target. It contains files, directories, links. Each of it have a owner, a group and attributes mode (rwx), smack labels.
- The relationship between packages (dependencies).
- The groups of packages.
The software will allow to:
- switch on a new set of RPM;
- navigate from the filesystem to the RPM (group, items, relation);
- add, modify, remove rules;
- evaluate the action of the rules and show untagged items;
- apply security rules to a target device;
- create the manifest files;
- check the existing manifest files.
José Bollo, EUROGICIEL, November 15th, 2013
(*) to not set a SMACK label is an option of knowing what label to put: none. It have to be taken into account.