Maneage - 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 |
Percent Complete: | 0% | Assigned to: | None |
Open/Closed: | Open | Effort: | 0.00 |
( Jump to the original submission )
Thu 30 Jul 2020 10:35:26 AM UTC, comment #13: |
Mohammad Akhlaghi <makhlaghi>![]() |
Thu 30 Jul 2020 06:32:46 AM UTC, comment #12: Thanks for the discussion Mohammad :-)
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:
|
Mohammadreza Khellat <mkhellat>![]() |
Wed 29 Jul 2020 09:01:54 PM UTC, comment #11: Thanks for the clarifications Mohammad-reza ;-).
|
Mohammad Akhlaghi <makhlaghi>![]() |
Wed 29 Jul 2020 11:21:41 AM UTC, comment #10:
Yeah as I mentioned, JAIL is a login shell.
Now getting back to my last argument, imagine the following scenario on a server:
|
Mohammadreza Khellat <mkhellat>![]() |
Wed 29 Jul 2020 10:40:58 AM UTC, comment #9: This is interesting Mohammad-reza, thanks ;-).
|
Mohammad Akhlaghi <makhlaghi>![]() |
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, ....
|
Mohammadreza Khellat <mkhellat>![]() |
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.
|
Mohammad Akhlaghi <makhlaghi>![]() |
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!
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sun 05 Jul 2020 04:28:39 PM UTC, comment #5: Few points regarding user namespaces,
|
Mohammadreza Khellat <mkhellat>![]() |
Thu 25 Jun 2020 04:03:48 PM UTC, comment #4: == A QUICK UPDATE ==
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>![]() |
Tue 23 Jun 2020 02:55:06 PM UTC, comment #3:
|
Boud Roukema <boud>![]() |
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!!!
|
Mohammad Akhlaghi <makhlaghi>![]() |
Sun 21 Jun 2020 06:18:34 PM UTC, comment #1: There's also some overlap with:
|
Boud Roukema <boud>![]() |
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.
OBJECTIVEAs 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.
MOTIVATIONAs 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.
|
Mohammadreza Khellat <mkhellat>![]() |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 |
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 ;-).