Adding a launcher to a binary allows to control some aspects of its execution environment of the target application. This is used to change the namespace (view of the filesystem) of the target application at launch time. An other mechanism is also setup: the process receives (or not) keys that can be checked by other applications for the purpose of controlling authorisations. When implementing this mechanism, lakes appeared on the extendibility of the /proc kernel's filesystem that we will expose here.
The mainstream user is now accustomed to install applications that declare needing privileges (GPS position, reading contacts, ...).
This kind of API privileges is hard to guaranty for native applications without a framework that linux does not provide by itself.
The described framework is made of 3 parts: - the installer - the launcher - the key manager
The installer is setting the launching mechanic. This is mecanic uses links, security extended attribute, and groups.
The launcher setups the namespace environment using namespaces and the authorised keys and launches the target application.
The key manager is a high efficient server that allows any service to ask if a process has a given key.
The mecanism of the authorisation keys allow privileges to be given once, never or to be asked by some popup daemon.
The key manager is made using a virtual filesystem implemented using FUSE for prototyping. But the study of this mechanism shown limitations of the /proc kernel filesystem and its link to the LSM. It does not allow to extend the subdirectories /proc/pid with security by process items. The question will be debated.
Speakers: José Bollo