5 ms·

* I will update the IPv6 stuff * Also the wireguard config * I will look into how I can allow the user to provide that information as the IP is pulled within

* I will update the IPv6 stuff * Also the wireguard config * I will look into how I can allow the user to provide that information as the IP is pulled within the doctor container * Noted on Firefox Thanks for the detailed comment EDIT: Just provided instructions in the repo for how to configure DDNS: https://github.com/IAmStoxe/wirehole#configuring-for-dynamic-dns-ddns https://github.com/IAmStoxe/wirehole#configuring-for-dynamic... Also modifed it so only the port 51820 is exposed preventing any unintentional exposure.

clankyclanker 6y ago
Have you considered producing a patch for the FreedomBox folks? Getting it into Debian would make it easily available to lots of users. https://salsa.debian.org/freedombox-team/freedombox/ https://salsa.debian.org/freedombox-team/freedombox/
- byteknight 6y ago
  I have not but that's only because I had never heard of it. Will check it out
windexh8er 6y ago
You can minimize a bit of the manual installation of Docker by leveraging the convenience script that's maintained by them [0]. [0] https://get.docker.com/ https://get.docker.com/
- byteknight 6y ago
  I'd rather not pipe to bash from curl.
  - windexh8er 6y ago
    Interesting take given your project is mostly an installer with a quick start of trusting a compose file.
    - byteknight 6y ago
      You think an unprivileged docker container is more dangerous than a curl to bash with sudo inside? I beg to differ. If you care to please elaborate as to why I would be better off piping to bash rather than installing per the documentation? I am honestly interested in your take.
      - windexh8er 6y ago
        Two things here, from my perspective... First is that trusting my suggestion is no different than trusting the instructions in your repo. Both can equally harbor nefarious things. So, the question is: do I trust Docker's script over someone that was just on the front page of HN? Probably. To address the technical side - there are a number of things that can be improved from a security point of view in your compose file: 1) Restrict any new privs. security_opt: - no-new-privileges 2) Drop all privs then selectively add. cap_drop: - ALL cap_add: - NETADMIN 3) Limit CPU and memory. deploy: resources: limits: cpus: '0.50' memory: 50M reservations: cpus: '0.25' memory: 20M 4) Change the running users - looks like all the containers are running as root, which is no different from the system user. There are others, but.. Just because the container isn't explicitly 'privileged' doesn't mean it's operationally safe.
  - rmetzler 6y ago
    I understand that it’s better to have less dependencies. And I understand that a pipe to bash thing can do more than a naive user would think. But the header of get.docker.com doesn’t pipe directly to bash anymore. You can inspect the downloaded shell script or compare hashes.
    - byteknight 6y ago
      The problem is where do we automate the pulling of the hash to verify against? I do not know of a source.

clankyclanker 6y ago

Have you considered producing a patch for the FreedomBox folks? Getting it into Debian would make it easily available to lots of users. https://salsa.debian.org/freedombox-team/freedombox/ https://salsa.debian.org/freedombox-team/freedombox/

byteknight 6y ago
I have not but that's only because I had never heard of it. Will check it out

windexh8er 6y ago

You can minimize a bit of the manual installation of Docker by leveraging the convenience script that's maintained by them [0]. [0] https://get.docker.com/ https://get.docker.com/

byteknight 6y ago
I'd rather not pipe to bash from curl.
- windexh8er 6y ago
  Interesting take given your project is mostly an installer with a quick start of trusting a compose file.
  - byteknight 6y ago
    You think an unprivileged docker container is more dangerous than a curl to bash with sudo inside? I beg to differ. If you care to please elaborate as to why I would be better off piping to bash rather than installing per the documentation? I am honestly interested in your take.
    - windexh8er 6y ago
      Two things here, from my perspective... First is that trusting my suggestion is no different than trusting the instructions in your repo. Both can equally harbor nefarious things. So, the question is: do I trust Docker's script over someone that was just on the front page of HN? Probably. To address the technical side - there are a number of things that can be improved from a security point of view in your compose file: 1) Restrict any new privs. security_opt: - no-new-privileges 2) Drop all privs then selectively add. cap_drop: - ALL cap_add: - NETADMIN 3) Limit CPU and memory. deploy: resources: limits: cpus: '0.50' memory: 50M reservations: cpus: '0.25' memory: 20M 4) Change the running users - looks like all the containers are running as root, which is no different from the system user. There are others, but.. Just because the container isn't explicitly 'privileged' doesn't mean it's operationally safe.
- rmetzler 6y ago
  I understand that it’s better to have less dependencies. And I understand that a pipe to bash thing can do more than a naive user would think. But the header of get.docker.com doesn’t pipe directly to bash anymore. You can inspect the downloaded shell script or compare hashes.
  - byteknight 6y ago
    The problem is where do we automate the pulling of the hash to verify against? I do not know of a source.