nassyweazy

Also you don't have to go full power mode for 4 hours, the important part is to be in the water and move as much as possible. I preferred on my end to do half-day at the beach and half-day at the swimming pool.

Deal was: exercise A LOT but not for an extended period of time, eat less (once a day) but eat food that I like in quantities that I enjoy.

I lost the first 45 pounds in 3 weeks by doing the following daily routine:

- 4 hours of swimming

- 1.5 hours of weights lifting

- 3 hours of swimming

- 2 hours of table tennis

1 BIG lunch, no other meal for the day, TONS of water.

Apps, books and all are completely overrated. Just be motivated and listen to your body, stop exercise when you reach your limit, rest, repeat..

The other 55+ pounds were lost over 2 years and a half without much exercise, just find the arrangement of fruits, lightweight cheese and vegetables + tuna that you love and eat it as often as possible.

There is currently no "superduper-safe-mode" that enforces `--tls-verify` at the daemon-level to prevent lack of client verification/whitelisting. This can be discussed, the issue obviously being the UX (that means getting proper certs, specifying them in the config etc..).

It is VERY hard to do runtime detection of mining apps for two reasons:

1) it's mostly CPU usage intensive work and only if you know what's the average amount of computer power needed by your application upfront will you be able to make a policy decision on which image to stop and how to adjust Cgroups resources. If you don't, you'll have to build a reference profile of a trusted image anyway to be sure of what's the expected behavior.

2) There is no other "malicious" activity that might be reported by runtime security tools (it generally doesn't trigger anything blocked by your seccomp/LSM/filesystem-integrity profiles).

------- How to protect against this -------

The best protection is at the build chain level. There are tools out there to "bless" and/or verify an image's content/creator. Notary and Docker Trust (higher-level abstraction based on Notary inside Docker) are two tools that allow you to do:

  - key management

  - signer management

  - trust management

It is crucial for people out there to make sure they only deploy trusted images and make decisions on what to run (CI or Prod) based on signature integrity of trusted images.

For a quick tutorial on Docker Trust and Notary, check this out: https://github.com/dockersamples/dcus-2018-hol/tree/master/s...

Stay safe and do not run unsigned/untrusted images!

We're working on a solution that would please most people for docker containers and services called the Docker Entitlements: https://github.com/moby/libentitlement

These Entitlements are high-level privileges for containers and services that could be baked in images, same way as macOS/iOS apps. These permissions would allow to create custom {seccomp+capabilities+namespaces+apparmor+...} profiles (effectively security profiles) for a better granularity in app sandbox configuration by app developers and ops.

The current POC has `docker run`, `docker service create` and even build mechanism working. The integration is actively being worked on and PRs are being prepared.

The issue you mentioned is already opened here: https://github.com/moby/libentitlement/issues/44

Feel free to have a look at it and open issues/participate or reach out through Github as I'm the lead and would love to discuss use-cases :)

Thanks for this post, we are currently looking into this issue and a solution in order to have the most secure behavior by default.