[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue
casey.schaufler at intel.com
Thu Oct 17 16:51:07 GMT 2013
> -----Original Message-----
> From: Jussi Laako [mailto:jussi.laako at linux.intel.com]
> Sent: Thursday, October 17, 2013 1:57 AM
> To: Schaufler, Casey
> Cc: dev at lists.tizen.org; Le Foll, Dominique
> Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded
> UID issue
> On 16.10.2013 18:57, Schaufler, Casey wrote:
> >> Even with single launcher it could run as non-root with it's own UID
> >> and just have enough capabilities to do it's task?
> > Certainly. Locking down the invididual POSIX capabilities is more work, but
> it's just work.
> One of the concerns I have with this one privileged launcher instead of non-
> privileged within-session launcher are pre-loading and pre-initialization of
> frameworks with plugins.
*Stop right there!*
Because the launcher will be setting the Smack label on the application (a requirement for application isolation) a within-session launcher will need privilege (at least CAP_MAC_ADMIN) if it's not using exec() and doing pre-loading or pre-initialization instead.
*OK, you can carry on now.*
> For example gstreamer can benefit quite a lot from pre-initialization.
> But if we allow third party to install plugins this opens a gaping security hole in
> the system, because part of the initialization is usually loading plugins from a
> directory and then requesting capabilities of those plugins. Now through the
> shared library entry points you can in this case gain elevated privileges.
> Generally of course you cannot trust plugins. That's why for example in
> gsignond we have a separate "plugind" per loaded plugin that handles
> communication between a plugin and daemon over IPC.
Yes, from a security standpoint that's one of the reasons we have separate processes. Plugins are a mechanism whose primary purpose is performance, but whose primary impact is on security.
More information about the Dev