Security/Configuring Device Security Policy and Software Sources
As was explained in Device Security Policy, this contains a list of known software sources, their trust levels, list of allowed ac domains and associated public keys. The policy can be created and later reconfigured at any time of device lifetime by installing packages that contain configuration information in their manifest files. These manifest files differ in syntax from the manifest files, described in Manifest file, since their purpose is not to configure a policy for an application package, but to configure the device security policy.
In fact, configuring the device security policy means building a software source tree that was explain in Ordering of Software Sources, assigning trust levels for its nodes, and in addition specifying the list of allowed ac domains for each software source. The typical manifest file that configures a software source has the following sections:
<manifest> <sw_source name="root" rank="20"> <origin type="ZYPPER"> <keyinfo> mQENBE6MJTABCAC6pAFN... </keyinfo> <access data="dir:/usr/local/var/repos/root" type="plaindir" /> </origin> </sw_source> </manifest>
where the attribute "name" defines a name of a software source, "rank" defines a relative trust level (see Ordering of Software Sources for more information) of a software source, attribute "origin type" is used to identify a repository type that is associated with this software source. Currently only the "ZYPPER" type is supported, and it allows configuring a zypper repository on the target device together with definition of a software source. The "keyinfo" field contains a base64 coded binary value of GPG public key of software source, "access data" contains a basic URL of software source (repository URL), and "type" contain a type of the zypper repository.
Upon installation of such manifest file, the device security policy will be updated to contain a definition of new software source, and a new zypper repository will be configured for it. The configuration is located in /etc/zypp/repos.d/ folder and file name is "sw_source_name.repo". For example, for the above defined software source, the file "tizen.org.repo" will be created with the following content:
[root] name=root enabled=1 autorefresh=0 baseurl=dir:/usr/local/var/repos/root type=plaindir keeppackages=0
More information about each of this settings and configuration of zypper repositories can be found in Zypper man pages. If there is no need to configure a zypper repository for a software source, the tag "access" and type="ZYPPER" in origin tag can be omitted.
The device security policy will look like this after the installation of root software source:
<config> <sw_source name="root" rankkey="/10020/10000.root"> <origin> <keyinfo> mQENBE6MJTABCAC6pAFNW9tCbLQt... </keyinfo> </origin> </sw_source> </config>
I.e. it stores the software source name, the result trust level (in the "rankkey” attribute) and associated public key. In order to define a list of ac domains that are allowed to be requested from this software source or explicitly denied for this software source, the following section should be added to a manifest configuration:
<allow> <ac_domain name="Applications"/> <deny> <ac_domain name="System"/> </deny> </allow>
This configuration allows to define ac domain names that can be requested by packages coming from this software source, as well as explicitly deny certain ac domains. For example, for the new software source "T-developer.org", it might make sense to deny the "System" ac domain, because the software source isn't trusted enough. It can be done via the following manifest configuration:
<manifest> <sw_source name="T-developers.org" rank="10"> <allow> <ac_domain match="*"/> <deny> <ac_domain name="System"/> </deny> </allow> <origin type="ZYPPER"> <keyinfo> mQENBE6K4Y4BCACuLYpZwxY4jf... </keyinfo> <access data="http://t-developer.org/repos" type="NONE" /> </origin> </sw_source> </manifest>
The attribute "match="*" indicates that all ac domains inherited from the parent software source are allowed, while the “deny” section below it indicates that from the list of allowed ac domains, the "System" access control domain is explicitly denied. If the section that defines "allow" and "deny" rules for a software source is omitted, then the software source inherits the rules from its parent software source. The root software source (the root of the software source tree) is by default allowed to grant accesses to all ac domains unless explicitly specified in "deny" section.
For the security purposes uninstallation of packages that configure software sources isn't allowed. Instead only autorised upgrades are possible.
NOTE: Currently in order for the key to be a valid key of sw source, the key must be imported in rpm keyring by running rpm import command on gpg export of public key.
rpm --import key.gpg
Signing the packages
All rpm packages for Tizen must be signed and packages that configure software sources aren't an exception. The only package that can be unsigned is the package that defines root software source, and that package is installed one of the first one during the image building procedure. Based on the package signature and list of known public keys in the device security policy, rpm plug-in determines the software source of a package. If a new software source is defined via configuration manifest contained in a package, this software source becomes a child of the software source that signed this package. So, for example, if the above described "T-developers.org" software source definition comes from a package that signed by the root software source, then "T-developers.org" software source becomes a child of the root software source in a software source tree (see Ordering of Software Sources for more information).
In order to sign packages with a key of a particular software source, the following command can be used:
rpm --addsign rpm_package_name.rpm
It requires having a valid gpg key pair in gpg key ring, and specifying the particular key in "~/.rpmmacros" file. For example, in order to choose the key pair associated with the root software source, the ".rpmmacros" file should look like:
%_signature gpg %_gpg_path /root/.gnupg %_gpg_name root %_gpgbin /usr/bin/gpg
Where “_gpg_name” is the name of the software source’s GPG key identifier. The GPG key pair can be generated using the "gpg --gen-key" command, and it should be an RSA key pair. After the key generation is done, the public key can be exported in base64 format, using the following command:
gpg --export -a root
Then, the result of the export, apart from the last line, must be copied to the "keyinfo" field of the configuration manifest for this software source, and after that the package with the manifest can be installed and rpm plug-in becomes aware about the new software source and associated public key.