4 ms·

These are the install instructions the docs say to use: $ git clone https://github.com/Y2Z/monolith.git $ cd monolith $ cargo install These are th

These are the install instructions the docs say to use: $ git clone https://github.com/Y2Z/monolith.git $ cd monolith $ cargo install These are the ones I used: $ git clone https://github.com/Y2Z/monolith.git $ cd monolith $ sudo docker run --rm -w "$(pwd)" -v "$(pwd):$(pwd)" -u "$(id -u):$(id -g)" rust cargo install That isolated the build process. Similar method to isolate the execution of the built project: $ cd target/release $ sudo docker run --rm -w "$(pwd)" -v "$(pwd):$(pwd)" -u "$(id -u):$(id -g)" rust ./monolith https://www.grepular.com Slightly related: I released a project last night for easily running node applications inside containers: https://gitlab.com/mikecardwell/safernode https://gitlab.com/mikecardwell/safernode - Without even having node or npm installed on the host system, you can still run commands like "npm install" or "npm start" to run node applications safely isolated inside ephemeral containers.

wolco 7y ago
For someone having trouble with npm and windows 10, the suggestion couldn't come at a better time.
jolmg 7y ago
Though I don't know the specifics, isn't it commonly advised to not rely on docker for secure isolation of potential malware?
- zymhan 7y ago
  It's certainly not as secure as a VM, without a lot of safeguards.
- mike-cardwell 7y ago
  I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape. To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway. Correct me if I'm wrong. My goal was to make things more secure, not completely secure. Previously, dodgy libs could read (and add) ssh keys into ~/.ssh/, take over my NPM account by fetching ~/.npmrc, grab a copy of my ~/.bitcoin/wallet.dat, and add a keylogger into my ~/.bashrc Now, at least it has to break out of docker first.
  - jolmg 7y ago
    > To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway. But I never said it was preferable to run directly on the host. There are other choices. > My goal was to make things more secure, not completely secure. There is no such thing as completely secure. The argument against docker is more along the lines of "is it really as secure as people think it is?" > I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape. I'm not sure docker was designed for the purpose of secure isolation, so if it fails to securely isolate, I'm not sure it would count as a bug.
    - cookiecaper 7y ago
      Linux relies on a concoction of properly-configured kernel subsystems to provide some level of isolation for containerized processes, and systems like LXD and Docker try to patch up the gaps. The cgroups interfaces don't offer much security stuff directly -- they're mainly about containing groups of process within certain resource consumption quotas, and afaik, don't really attempt to contemplate secure isolation directly. LXD approaches this by adding a uid/gid translation layer, so that the uid/gid for anything within an unprivileged container will be offset by a specified value, e.g., calls with user ID 1000 in a container are made to present to the host as user ID 1000000. This comes with its own host of issues which LXD tries to hide. The short answer is that if security is any type of priority for the system in question and you want to run containerized processes, you should use an OS that implements container security directly in the kernel, like FreeBSD with jails or illumos with Zones, instead of depending on getting exactly the right configuration between all the moving pieces in the Linux container stack.
      - hollerith 7y ago
        I have no recent information, but about 10 years ago FreeBSD maintainers were telling people not to rely on jails for security.
  - geggam 7y ago

wolco 7y ago

For someone having trouble with npm and windows 10, the suggestion couldn't come at a better time.

jolmg 7y ago

Though I don't know the specifics, isn't it commonly advised to not rely on docker for secure isolation of potential malware?

zymhan 7y ago
It's certainly not as secure as a VM, without a lot of safeguards.
mike-cardwell 7y ago
I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape. To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway. Correct me if I'm wrong. My goal was to make things more secure, not completely secure. Previously, dodgy libs could read (and add) ssh keys into ~/.ssh/, take over my NPM account by fetching ~/.npmrc, grab a copy of my ~/.bitcoin/wallet.dat, and add a keylogger into my ~/.bashrc Now, at least it has to break out of docker first.
- jolmg 7y ago
  > To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway. But I never said it was preferable to run directly on the host. There are other choices. > My goal was to make things more secure, not completely secure. There is no such thing as completely secure. The argument against docker is more along the lines of "is it really as secure as people think it is?" > I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape. I'm not sure docker was designed for the purpose of secure isolation, so if it fails to securely isolate, I'm not sure it would count as a bug.
  - cookiecaper 7y ago
    Linux relies on a concoction of properly-configured kernel subsystems to provide some level of isolation for containerized processes, and systems like LXD and Docker try to patch up the gaps. The cgroups interfaces don't offer much security stuff directly -- they're mainly about containing groups of process within certain resource consumption quotas, and afaik, don't really attempt to contemplate secure isolation directly. LXD approaches this by adding a uid/gid translation layer, so that the uid/gid for anything within an unprivileged container will be offset by a specified value, e.g., calls with user ID 1000 in a container are made to present to the host as user ID 1000000. This comes with its own host of issues which LXD tries to hide. The short answer is that if security is any type of priority for the system in question and you want to run containerized processes, you should use an OS that implements container security directly in the kernel, like FreeBSD with jails or illumos with Zones, instead of depending on getting exactly the right configuration between all the moving pieces in the Linux container stack.
    - hollerith 7y ago
      I have no recent information, but about 10 years ago FreeBSD maintainers were telling people not to rely on jails for security.
- geggam 7y ago