[task #15701] Sandboxing the execution of the project

[Mohammadreza Khellat]

Follow-up Comment #5, task #15701 (project reproduce):

Few points regarding user namespaces,

First thing first, lets check if the host allows creation of new/unprivileged
user namespaces
By default, kernel versions 3.8 onward are compiled with the option
_CONFIG_USER_NS=y_ which would allow creation of user namespaces. However,
* in order to disallow the creation of user namespaces altogether, people
might recompile the kernel with _CONFIG_USER_NS=n_. 
* it is also possible to disallow creating _new_ user namespaces by modifying
_/etc/sysctl.conf_ or _/etc/sysctl.d/_ on the host and adding
_user.max_user_namespaces=0_.
* and finally, it is a normal practice among specific distros to disallow
creating unprivileged user namespaces by playing with the
_kernel.unprivileged_userns_clone_ sysctl knob. Clearly, the result of this,
is that you would get a permission denied running


unshare -U bash


Secondly, if a normal user on a host can create a new user namespace, s/he can
create this user namespace with _--map-root-user_ which would map the normal
user to _eUID 0_ inside the new user namespace and its children namespaces by


unshare -U -r bash


after this, s/he would have the full _effective capabilities_ inside that user
namespace and all its children (all namespace created under that user
namespace).

Now comes the magic, running the above command, you would be privileged inside
the created user namespace hence even you can create mount, IPC, network, UTS,
... namespaces which would require _CAP_SYS_ADMIN_. In fact, it is more
interesting, you can create all these namespaces in a single run. For
instance, a normal user can create a new user namespace and a mount namespace
under that user namespace with the follwoing


unshare -U -r -m bash


Now lets say, one would do _unshare -U -r bash_ and then he wants to do a
_chroot_ to the project directory. The relevant mount points for _/bin,
/usr/bin, /lib, ..._ should exist in the project directory. Apart from that,
there are ways to gain access from inside a _newroot_ to the original root,
hence system admins use different methods to contain such access. You may
refer to following
https://lwn.net/Articles/252794/
https://www.redhat.com/sysadmin/set-linux-chroot-jails

I think we should continue working on this in two directions: one can be a
chroot-jail sort of thing in combination with LFS, and second focusing on a
combination of namespaces to create the contained environment with appropriate
capabilities.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?15701>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/