Contents |
The MeeGo TV 1.2.2 update is the first release of MeeGo TV that contains the initial enablers for implementing security on TV platforms. These enablers should help manufacturers of TV platforms to protect the operating system from the potentially bad consequences that can be caused by installation of malicious software. However, the provided components do not guarantee any additional security without having proper security policy in place and at this point of time are provided with the goal of getting familiar with security components, interfaces and etc. The examples of referenced security policy for the basic system components will be provided in the future releases. This release should be useful for the TV platform manufacturers and developers who are interested to get preview of the initial security enablers, get to know the available interfaces, understand the restrictions and benefits that come from using the security framework and experiment with placing the policies for their applications and packages.
The main addition of this release is the fact that MeeGo 1.2.2 kernel has Smack LSM [1] turned on that in turn enables usage of the Smack access control features. When the image boots, the virtual smack filesystem (smackfs) is mounted at the /smack mount point and therefore enables the communication between the kernel Smack LSM component and the userspace. By default all processes in the system and all filesystem objects gets assigned to the ”floor” system access control (AC) domain or in Smack terminology gets assigned a floor (visible as “_”) label and there are no any restrictions on the communication or any kind of access apart from that is being enforced by the Linux default Discretional access control (DAC) [2].
In order to change the default assignment of the AC domain for a certain application, its package must contain a manifest file where developer can request to belong to a certain AC domain. More information on how to create manifest file can be found in the “Manifest file” section of [3]. By default only the “floor” system AC domain is defined and can be requested currently by any package. In order to request to belong to any other domain developer must first define the domain the manifest file together with the desired set of access control rules. More information on defining new domains can be found in the “Defining a new domain” section of [3]. When the package with a manifest file is installed, the package manager (rpm) verifies the correctness of manifest: its syntax and whenever the requested domain or accesses can be granted. In this release any type of requested domain or access is granted given that the domain is defined and not marked as private (see the same section of [3]). After the verification is done, the package gets installed, the files from the package gets proper extended attributes with the label of requested domain; and the access control rules (if any) are added to the file /etc/smack/accesses.d/<package_name>. The overview of the package manager security extension and its logic can be found in [3].
In addition to restrictions enforced by the Smack AC on the filesystem access and IPC communications between processes (shared memory, local and network sockets), additional restrictions can be enforced by any process in the userspace using the provided libsmack library. It contains an API to check if certain process can access certain object in a way specified in the access type field. Also there is an API to retrieve the label of the process behind the socket connection or the API to get the self-label of the process. In addition libsmack library has the APIs to manipulate the set of smack access control rules in the kernel, but this API requires CAP_MAC_ADMIN capability. The man pages for libsmack interfaces can be found in [4].
The dbus daemon in MeeGo TV 1.2.2 release is also enhanced to include additional security AC checks based on Smack. The default behaviour is to allow any type of communication on the dbus, but communication can be restricted by specifying the interfaces and methods that should be allowed to be used only by processes with appropriate access rights. More information about dbus security enhancements can be found in [5]. The restrictions on dbus interfaces can be specified in the manifest file of the package. Please refer to the section “Protection of dbus interfaces” of [3] for more information.
The interface of libsmack, format of manifest and dbus configuration files are rather stable and supposed to be supported in the future releases. Some changes are possible to the syntax of manifest in the future in order to enrich the functionality.
In order to validate the functional side of all listed security features, we used the following tools:
1: Validating the SMACK component is done using the automated scripts in the Linux Test Project [6].
The Linux Test project is a collection of resources for testing the reliability, robustness, and stability of Linux. Among those resources, some are aimed at testing the SMACK filesystem. We had to slightly modify those scripts themselves as some were returning false negatives. Also a few extra packages are needed to install and run the LTP tests. The following packages are needed to install and run the LTP: bison, flex, make, gcc, attr.
2: Validating SMACK and DBUS integration was done using Brian Mcgillion's smack-demo app [7].
The application installs a server-client pair and enforces SMACK use for DBUS and socket communications. The application needs the following packages to build and run: smack-qt, smack-qt-devel, libqt-devel, make, gcc-c++, attr. Also please see Brian's wiki for further info on the DBUS security enhancements [5].
3: Validating the RPM was done using an automated suite that checks that offline installation of packages is done in the correct security context, that files installed by the package are given the correct security attributes, that packages containing incorrect or malformed manifests are not installed as well as other checks on different scenarios involving the security plugin for RPM. See Security Aspects of SW Distribution and Application Installation [3] for more details.
[1] Smack LSM, http://www.kernel.org/doc/Documentation/security/Smack.txt [2] Discretionary access control, http://en.wikipedia.org/wiki/Discretionary_Access_Control [3] Rpm security changes wiki, https://wiki.tizen.org/wiki/Security/Application_installation_and_Manifest [4] Smack userspace man pages, https://github.com/brianmcgillion/smack/tree/master/doc [5] Dbus security enhancements wiki, https://github.com/brianmcgillion/DBus/wiki [6] Linux Test Project, http://ltp.sourceforge.net/ [7] Brian McGillion's smack-demo app https://github.com/brianmcgillion/smack-demo
Ask your questions on meego-security-discussions mailing list.