ubuntu-phone team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxx>]

On 2015-07-28 18:01:56, Zoltán Balogh wrote:
> If you have any experience or opinion about the topic please bring it up :)
> 
> This idea looks very promising and piling off seconds from the app starts is
> something we all are interest, but obviously not for the price of
> compromising our platform's security.

I want to talk about the security concerns and areas that would need to
change. I've not yet had a chance to closely review the code and I'm
mostly going by the description that you linked to. I've pulled it into
my reply:
 
> 1. Start qml-boooster
> 2. qml-booster: starts as the daemon process
>    --> Deamon::run() https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L159
> 
> 3. qml-booster: forks itself to become the actual booster (that will become the app)
>    --> https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L184
>    --> Daemon::forkBooster() https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L358
> 
> 4. preforked process: clean up after fork:
>    --> https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L374

This stage is not sufficient since there is no exec() performed here.
This removes the possibility of per-process address space layout
randomization (ASLR). All processes on the system that were spawned by
qml-booster will have the same memory layout, even if the program
authors are trying to do the right thing by building with -fPIE.

The exec() will need to occur after special process initialization such
as setting rlimits, configuring cgroups, etc., but before attempting to
preload any libraries.

I've prototyped the difference with a simple proof-of-concept of a
booster daemon and app program and the exec() slows down things a
considerable amount. Any benchmarks should definitely include such a
change in order to not get any hopes up by looking at the non-exec()ing
benchmark numbers.

Also, AppArmor profile transitions are much more complete when they
happen across an exec(). The qml-booster daemon process should be
loosely confined by an AppArmor profile. When the exec() occurs, it'll
transition to a much more confined profile for the preforked process.

> 5. preforked process:
>    --> initializes the booster caches (load predefined QML components) and waits for invoke
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L413
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L68
> 
> 6. user requests app to start
> 
> 7. preforked process:
>    --> send message to parent that it needs to prefork a new booster, then closes the socket
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L141
> 
>    --> start to execute the actual app:
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/daemon.cpp#L424

The preforked process will now need to transition to the AppArmor
profile for the app by means of aa_change_profile().

Tyler

> 
>    --> last cleanup before app is started
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L254
> 
>    --> Dlopen the binary and load the "main" symbol to execute it:
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L424
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L452
> 
>    --> Finally execute main
>        https://github.com/nemomobile/mapplauncherd/blob/master/src/launcherlib/booster.cpp#L443
> 
> 8. After the app was closed, the preforked process dies with it

Attachment: signature.asc
Description: Digital signature