You can run docker rootless too. On local machines running docker with root is a risk that for many is acceptable. On servers and publicly exposed hosts, rootless.

I have also discovered very interesting blogs or site that I have then added to my RSS feed. They also offer a lens to only look within the small web, which they index themselves I think.

He has not been sentenced already, I hope you know that. I hope you also know the effort that he and his team made to have the trial been done where he was de-facto prisoner, but also the completely lack of flexibility from those who wanted him to simply step out of the embassy to arrest and extradite him.

The timeline and the events are very well narrated in Stefania Maurizi’s book. It’s almost gross how much the rape accusations have been used to try to get to him and how poorly both British and Swedish authorities behaved, probably obeying to the US (colonial power much).

I have no problem with Proton drive for simple Directory-based backups (Windows only AFAIK at the moment). That said, it is not a specialized backup solution, and for that I think something like backblaze is much better (and cheaper, possibly).

On the other hand, you can approach the dramatic cut of emissions from both angles, as in “you are not legally able to do what you want as long as you can pay for it, and you have the responsibility in minimizing emissions”.

Internet does generate a lot of emissions. Streaming quality, website size. Whatever we do to reduce the energy demand is a good idea, as long as we don’t think of it as " The Solution", but as part of a wide range of actions aimed at slashing energy consumption.

I want to add a small bit of info that might be useful in the future. Your script doesn’t need really to be run with root privileges. Your backup script likely needs access to parts of the filesystem which are only readable from root but that’s all it needs. The root privileges are essentially a combination of capabilities (see man capabilities) attached to processes. In your case, what you want is the CAP_DAC_READ_SEARCH, which allows read access to every file. You can for example add this capability to rsync (or more likely, to Borg,restic or rustic - which are backup tools I recommend you look at! They do encryption, deduplication etc.) and then you can use that binary as a low-privileged user, but having that slice of root privileges. Obviously, there is a risk in this too, but can be compensated in other ways as well (for example running the backup job in a sandbox etc. - probably out of scope for now).

While in this particular case it might not be super relevant (backups are executed often as root or as a backup user which has read access), it might be useful in the future to know that very rarely full root privileges are needed, and you can run tools only with the specific capability needed to perform that privileged action. You can check setcap and getcap commands.

It’s also not too hard to cook a Dockerfile for it, or even write a systemd wrapper with security settings. However, with flatpak you get this out of the box and mostly in a transparent way, plus you get all the usually annoying aspects (like having GUI applications work in containers) taken care of.

Tbh, for me the value of flatpak is in the isolation (great for how easy it is to achieve), rather than the compatibility.

For example, I run obsidian with no network access and fs access to just the path where my notes are stored. This is really reassuring considering I am not really sure what all the plugins might do. While it is not perfect, it’s much better than having it running natively in my box (I.e. root namespaces).

It’s the de-facto standard for runtime container security (sysdig is based on it). The only competitor afaik is aqua security’s tracee, which is way less mature. It is very well supporter, there are tons of rules maintained by the community and it is a CNCF project used by enterprise solutions (I.e., shouldn’t disappear overnight).

Yeah, that sounds even better.

wut?

personal data have not been obtained from the data subject

Reads to me like data that I (data subject) did not provide myself, but that the processor collects. I guess an example could be IP address.

You already mentioned the most important things.

I will add, at the cost of being pedantic:

• build the image properly, or use good images. This means limit dependencies as much as possible, as minimal images as possible (less updates due to CVEs, less tooling).
• do not mount host volumes, if you really have to, use a dedicated subpath owned by the user of the container. Do not use homedirs etc.
• do not run in host namespaces, like host network etc. Use port mapping to send traffic to the container.

If you want to go hardcore:

• analyze your application, and if feasible, build and use a more restrictive seccomp profile compared to the default. This might limit additional syscalls that might be used during an exploitation but that your app doesn’t need.
• run falco on the node. Even with the default set of rules (nothing custom), many exploitation or posts-exploitation steps would be caught, such as “shell spawned” etc.

If you containerize, the application (malware) will run under the user configured in the image, unless you override it, and in a separate mount namespace, unless you change that, which makes the “alias sudo” trick extremely unlikely.

Even running under a separate user anyway prevents almost fully the attack you mention, unless the separate user has root privileges or the DAC_OVERRIDE capability is assigned to the binary (assigning it requires CAP_SYS_ADMIN).

In short, the attack you mention is a common persistence and privilege escalation vector, which is relatively easy to detect (watch for changes to shell profiles), although preventing it requires some care. I just want to point out that in single-user machines (e.g. personal computers) escalating to root is anyway fairly unnecessary, given that all the juicy stuff (ssh keys, data, etc.) is anyway probably running under/owned by that user.