> -----Original Message----- > From: Jussi Laako [mailto:[email protected]] > Sent: Thursday, October 17, 2013 1:57 AM > To: Schaufler, Casey > Cc: [email protected]; 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
