taskManeage - Tasks: task #15701, Sandboxing the execution of the...


You are not allowed to post comments on this tracker with your current authentication level.

task #15701: Sandboxing the execution of the project

Submitter:  Mohammadreza Khellat <mkhellat>
Submitted:  Sun 21 Jun 2020 05:52:48 AM UTC
Should Start On:  Sun 21 Jun 2020 12:00:00 AM UTC Should be Finished on:  Tue 21 Jul 2020 12:00:00 AM UTC
Category:  Software Priority:  5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  None Percent Complete:  0%
Open/Closed:  Open Effort:  0.00

Jump to the original submission

Thu 30 Jul 2020 10:35:26 AM UTC, comment #13: 

Thanks Mohammad-reza, this is a good outline of what we have planned so far. But indeed, it isn't set in stone, and we should be critical to every step.

For example, ideally we would want to use 'chroot', but in some scenarios it may not be possible (the server kernels may not allow namespaces). So Maneage should be able to work similarly in situations where namespace generation and chroot are not possible. This is just a trivial conditional check at the start of the process, so it doesn't worry me too much. I just mean to say that we want the user (for example myself when I put myself in paper-writing shoes!) to not have to worry about these things ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Thu 30 Jul 2020 06:32:46 AM UTC, comment #12: 

Thanks for the discussion Mohammad :-)

Yeah, I completely agree. LFS is a good approach and with proper fine-tuning, it could become minimal and robust.

I think, with this approach, this is what you have in mind:

  • build the basic structure required for LFS without root privileges and capabilities
  • restricting filesystem access of the rest of the project scripts to the project directory using a user namespace and a nice chroot which uses the built LFS.

unshare -U -r bash

chroot "$LFS" <LFS_ROOT>/bin/env -i HOME=<LFS_ROOT> TERM="$TERM" PS1='\u:\w\$ ' PATH=<LFS_PATH_VAR> <LFS_ROOT>/bin/bash --login +h

  • and from now on the rest of the project script is run inside this chroot environment without filesystem access to anything outside the project directory.

Please correct me if I have assumed anything not inline with the existing plan.

P.S. As someone with tendency towards a theoretical mindset and
being always in awe of self-consistent constructs ;-), if I wanted to perfect this approach, I would have slightly modified the first step:

  • I would have tried to build the LFS itself inside a minimal chroot'd environment composed of the minimal things that you would need from the existing host OS to build that nice-looking LFS construct. :-)

Mohammadreza Khellat <mkhellat>
Group Member
Wed 29 Jul 2020 09:01:54 PM UTC, comment #11: 

Thanks for the clarifications Mohammad-reza ;-).

Yes, I agree, we should look into many implementations and find the most robust and minimal. Currently we do build an almost complete environment. It is only missing the GNU C Library, and we have also made some progress on that front in task #15390. In that task, we are following the prescriptions of Linux from Scratch.

Once the C library is built from source, we have all the other components of a minimal (for a scientist!) environment to easily chroot into.

But as I mentioned, this is based on Linux from Scratch. We may find other solutions to learn from, so there is absolutely no insistence on it.

The only important thing is a robust system that we can build from source without requiring anything from the user or system administrator.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 29 Jul 2020 11:21:41 AM UTC, comment #10: 

comment #9:

> If I understand correctly, it requires a log-in by the user and wraps over their shell. We can't force users to do this! A principle of Maneage is to have no effect on the host ;-).

Yeah as I mentioned, JAIL is a login shell.
And It is going to be used as the default shell of a user.

I suggest going through the full configuring Jail section. It is a quick easy read.

But, as I mentioned at the top of my comment, the reason I shared this site is to see what a minimal chroot environment is composed of.

If you remember, the discussion last time reached this point that we couldn't do a chroot to the project's folder because some system components didn't exist in the project folder such as /bin/bash,...

> You also mentioned one-time engagement of root privilege, which we also can't assume in Maneage.
> Please correct me if I am wrong ;-).

Now getting back to my last argument, imagine the following scenario on a server:

1- the server admin has created a user for jailed chroot. This user has /usr/local/bin/jail as its defau;t shell in /etc/passwd or what other user management system, the server is using.

2- You as an ordinary user login to your own shell.

3- you create a user namespace.

4- inside the user namespace, you login to that user created in step 1 and you run your project with that user.

Of course, I am not suggesting this in general. Only, as a test in Server environments and as a very raw idea.

Mohammadreza Khellat <mkhellat>
Group Member
Wed 29 Jul 2020 10:40:58 AM UTC, comment #9: 

This is interesting Mohammad-reza, thanks ;-).

I had a fast look in its How Jail works page and noticed this: "Jail is a login tool. Jail works as a wrapper to the user shell, so when the user log in the machine Jail is launched, and the chrooted environment is activated. Then, Jail execs the real user shell, so he gets his session in the server."

If I understand correctly, it requires a log-in by the user and wraps over their shell. We can't force users to do this! A principle of Maneage is to have no effect on the host ;-).

You also mentioned one-time engagement of root privilege, which we also can't assume in Maneage.

Please correct me if I am wrong ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 29 Jul 2020 09:56:40 AM UTC, comment #8: 

A quick update on this on how to create the chroot environment, in terms of what block devices, ... would be required from /dev, ....

A nice login shell called jail from 2001, and the discussion there,


Of course, for us, the mechanics of the perl script which would create the minimalist chroot environment has the highest priority. This could nicely fit to the philosophy of creating the minimalist environment required to build and run a project.

The code can be downloaded from

I will be working on combining this with an unprivileged user namespace.

However, the general Idea of a jailed login shell in a server environment is very effective and would require one-time engagement of root privilege.

Mohammadreza Khellat <mkhellat>
Group Member
Sun 05 Jul 2020 08:41:48 PM UTC, comment #7: 

I should just add that GNU C Library can't be built on macOS. So even if we can use 'unshare' on macOS, we can't build the GNU C Library.

But I am not sure if it can be cross-compiled from a GNU/Linux distro for example for the macOS kernel. If it can be cross-compiled, we may be able to distribute the binary cross-compiled GNU C Library binaries to use on such systems. But anyway, this is better to discuss this in task #15390. An alternative option would be to try LLVM's compiler infrastructure. But I am not too familiar with that.

By the way, just for fun, the "fake root" comment could also have been written as "rootless root", which reminded me of reminded me of SUPER-ENTERTAINING and deeply thoughtful Rootless root (The Unix Koans of Master Foo!). If you haven't read them, I strongly encourage it, they are GREAT!

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 05 Jul 2020 08:13:18 PM UTC, comment #6: 

Very nice summary Mohammad-reza, I really enjoyed reading it and also learnt a lot!

As an initial test, I made a 'temporary' directory in my home account on one of our servers. Just to confirm that 'chroot' doesn't work, I tried 'chroot'ing to it and got an "Operation not permitted" result:

$ chroot temporary/
chroot: cannot change root directory to 'temporary/': Operation not permitted

Then I started following your examples. The first command worked and I became "nobody":

[me@server ~]$ unshare -U bash
[nobody@server ~]$

The second command also worked and I became "root":

[me@server ~]$ unshare -U -r bash
[root@server ~]$

The third command also worked, just to confirm that this root is fake, I also tried going to the root directory and writing something there:

[me@server ~]$ unshare -U -r -m bash
[root@server ~]$ cd /
[root@server /]$ echo "test" > test.txt
bash: test.txt: Permission denied

Then, in my home directory, I ran the first 'chroot' command above and this time it didn't complain about permissions any more (so it passed that phase!). But it complained about not finding '/bin/bash' in the newly rooted directory (which was expected because the directory was empty!):

[root@server ~]$ chroot temporary/
chroot: failed to run command ‘/bin/bash’: No such file or directory

So this does seem like a promising path! What do others think?

'unshare' is part of 'util-linux', which also builds on macOS. I really wonder how this would work on macOS. Raul, if you get the chance later, can you try it out?

But over-all, as you said, if we can do a 'chroot', then the next step would be task #15390 (Installing GNU C Library within project). Fortunately some good progress has been made on that front, with the basic Make recipes being written for a successful ly usable C library, but there is still some work necessary to for the later parts of that task...

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 05 Jul 2020 04:28:39 PM UTC, comment #5: 

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

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.

Mohammadreza Khellat <mkhellat>
Group Member
Thu 25 Jun 2020 04:03:48 PM UTC, comment #4: 


I am following/evaluating user namespace sandboxing.

For some keywords and resources, you may refer to the following:

NOTE: Michael Kerrisk is the maintainer of Linux man-pages; as you might know, the man-pages were originally created/published as the main documentation of UNIX.

Mohammadreza Khellat <mkhellat>
Group Member
Tue 23 Jun 2020 02:55:06 PM UTC, comment #3: 

comment #2:

> I must confess that the scenario you described with "rm -rf" happened to me once! Fortunately I wasn't root, but before I could understand the mistake, my home directory was gone!!!
> But Looking back at that experience, it happened while I was developing my own project (it was a simple typo that can happen in any script!).

Software security should in general have many layers, with each assuming that other layers may make mistakes. One layer to prevent that sort of error is following recommended programming practices. I'm not an expert in that, but I try to follow the styles that I see as recommended.

I've started the task
for the issue of curly brackets in parameter names for the generic shell and for bash. I tend to think that that could reduce the probability of this sort of catastrophic error.

Boud Roukema <boud>
Group Member
Mon 22 Jun 2020 10:42:43 AM UTC, comment #2: 

I must confess that the scenario you described with "rm -rf" happened to me once! Fortunately I wasn't root, but before I could understand the mistake, my home directory was gone!!!

But Looking back at that experience, it happened while I was developing my own project (it was a simple typo that can happen in any script!).

Running something like Lintian on every test run of the project will make it slow and probably many will just disable it!

Generally when packaging Gnuastro for Debian I like the Lintian wornings! Like the spell-checking in the source code and comments ;-)! But I agree maintaining something like Lintian will be too much work for us now!

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sun 21 Jun 2020 06:18:34 PM UTC, comment #1: 

There's also some overlap with:
https://savannah.nongnu.org/task/?15682 - maneage-lint
which is meant to be for the general task of a 'lint' program in general, not only for shebang issues.

A lint type program can only detect common types of errors or security flaws (e.g. rm -fr where the argument can by accident become / or go up in the directory tree), and a detector script needs to be written for each of these.

Given that the Debian lintian is already highly developed - see https://savannah.nongnu.org/task/?15682 - it would be worth learning from that experience. As I pointed out there, the detector scripts have to be themselves debugged. :)

The general sandbox idea is good. I assume that examples would be chroot and debootstrap, which uses chroot :

Boud Roukema <boud>
Group Member
Sun 21 Jun 2020 05:52:48 AM UTC, original submission:  

In parallel to the security-oriented/security-related discussions in

I am opening this task to discuss the implementation of an effective/simple/platform-independent sandboxed environment for the execution of Maneage project scripts.


As a first step, we might try limiting filesystem access of Maneage project scripts to their parent directory while forbidding their access to specific locations/files (such as all the hidden files and directories inside $HOME) even if the Maneage project scripts parent directory contains such locations.


As a scientific research project management/workflow pipeline, Maneage has been designed with the purpose of providing transparency and clarity to the workflow of scientific projects branched from it. This is achieved by writing scripts and taking advantage of Make-files to create the relevant workflow. This means that one would gain full visibility to data lineage and workflow of the Maneage project by going through the project scripts and MakeFiles.
It is true that no Maneage project cannot NOT PROVIDE these scripts and MakeFiles, however, in practice a thorough review of scripts and the MakeFiles could not be that easy.

It is going to be easy to miss things specifically when an inexperienced Maneage project audience is trying to first test and then to understand another person's research workflow for his own sake. The story is different when someone wants to create his own Maneage project.

After two to three Maneage projects, that person would surf through the scripts and the MakeFiles very quickly and would not even have the urge to run the scripts to understand the workflow. When clarity is achieved regarding the workflow, to check the results or to play with the workflow, s/he might find it necessary to run/modify the project.

Long story short, It is not practical to fully transfer the responsibility of reviewing Maneage branched projects codes to either the audience or the Maneage developers.

Mohammadreza Khellat <mkhellat>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by boud (Posted a comment)
  • -email is unavailable- added by mkhellat (Submitted the item)
  • -email is unavailable- added by mkhellat
  • -email is unavailable- added by mkhellat
  • -email is unavailable- added by mkhellat
  • -email is unavailable- added by mkhellat

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-06-21 mkhellat Carbon-Copy- Added boud
        Carbon-Copy- Added infantesainz
        Carbon-Copy- Added makhlaghi
        Carbon-Copy- Added pedram

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code