[Dev] Multi User activation idea.

Łukasz Stelmach l.stelmach at samsung.com
Wed Oct 2 14:00:03 GMT 2013

It was <2013-10-02 śro 13:06>, when Dominig ar Foll (Intel OTC) wrote:
>> UID namespaces are considered problematic, to say the least. The
>> problems begin when you create files in a UID namespace. Then, the
>> security team (I've just asked them to write a little bit more about it
>> here) has their own idea of how to use containers.
> Our idea is to create the User NS with a static mapping in such a way
> that the control from the root name space remain possible in a
> traditionnel way.

The problem I've been introduced to is different. What happens if an
inside-ns-uid-0 process creates a 02755 (suid 0) file? It should be
mapped to the outside uid. What gets on disk there is a
uid-ns-in-uid-ns? In general UID ns seems to me very tricky.

Anyway, why would you like to make services think they run as root when
in fact they don't?

>> I am afraid you trust containers too much and forget about real security
>> measures (SMACK in our case). Containers are not meant to provide
>> security.
>> http://www.youtube.com/watch?v=Sz-S7fqgjvA&feature=player_detailpage#t=485
>> I hope, I wrote something useful.
> I am not proposing to rely only on the containers for security but
> just to try to optimise RAM by sharing ressource when possible
> beetween users without running all the common services as root.
> My view is to keep SMACK as well.

Why not then make services run as ordinary users like dbus-daemon.

--8<---------------cut here---------------start------------->8---
$ grep messagebus /etc/passwd
$ ps U messagebus
  904 ?        Ss     0:00 dbus-daemon --system --fork --activation=upstart
--8<---------------cut here---------------end--------------->8---

A service started by the system instance of systemd chroots, drops
capabilities it does not need, switches to a non-privileged users et
voilà. This is "Ye Olde Way We All Know". Ad SMACK to taste.

Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131002/c5a86c88/attachment.sig>

More information about the Dev mailing list