-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/29/2015 07:07 AM, Tyler Hicks wrote: > 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.
Can you elaborate a bit on the risks of not having ASLR? As I understand it, since the process is confined, it still won't be able to perform any action that a malicious application wouldn't be able to do, right? If I understand correctly, the risk associated to not having ASLR in the mapplauncher'ed applications could be exploited by an attacker by having the user run a malicious application which reads its memory layour and dump it over the internet to the attacker, which would then have to exploit a bug in another application, and at this point he could reliably know that this application will have the same memory layout than the malicious one (at least as far as preloaded libraries are concerned). And even in this case, the risk is mostly about the user data associated with the application. I don't want to say that this is not an important issue, but I'm sure it's definitely not important for many apps. Since using mapplauncherd would anyway be optional, we could explain the risks of using it, and let developers decide. At least, I can imagine these risks to be rather irrelevant for most games and utilities, and indeed for all apps not accessing the network. (I'm not saying we shouldn't try to address this issue, by all means! - -- continue reading below for an attempt. I'm saying that if it turns out that integrating mapplauncherd in a way that preserves ASLR defeats its performance gains, we should still have it available in the "unsecure" way, for people who want it) > 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. But the exec() does not necessarily need to load the application, right? It could happen when the user has not yet chosen which application to start, and instead of executing an app, it could exec() into a loader process which does all library preloading and initializing, and then (when the user launches an app) dlopen the app, close any unneeded file descriptors, call aa_change_profile and finally run main(). Then of course it would have to quit, and not be reused. This would still preserve the ASLR, wouldn't it? Ciao, Alberto -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlW4jfMACgkQVLQegMXeCFIaOACbB70Oysbr5SZu818NEEqXvQth OwoAnRNJGerWBg/h96aDdAIteiKc7uyZ =UbCc -----END PGP SIGNATURE----- -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
