In my opinion the biggest advantage of podman is that it uses pods with basically the same config and behavior as kubernetes does. As long as you just use podman pods instead (or possibly via) compose files you likely just notice that only the pod has one (and not any more) veth interface, that you reach other containers inside a pod via localhost:$port (instead of $service-name:$port) but when you switch later on to kubernetes you are already familiar with some basics.
Why would an adversary being able to execute code as root on a personal computer be a bigger threat than their being able to execute code as non-root? Surely just about any of the stuff that a malicious hacker might want to do to someone's personal computer can be done without root... right?
For one, as non-root user you are tied to the permissions system and can't access most of the data.
If one of your services (let's say sql) get hacked, they are tied to sql user, and unless the achieve privilege escalation, they can't mangle with other services data (eg webserver).
Also network wide, a non-root user can't use different protocol than tcp and udp.
The only reason you can ping as a regular user is because of the setuid on the ping program, otherwise icmp is not allowed to non-root users.
There are of course other reasons, but these are some examples on how it would be different.
I think you're just illustrating my point. Those concerns don't apply to personal computers and they don't stop an intruder from doing anything they might practically want to do for gain. Like installing ransomware, participating in a botnet, exfiltrating personal files/browser cookies/etc (all accessible as non-root!), ...
Apart from rootkit and backdoors that are more difficult to install as non-root, you cannot build specific tunnels as you don't have network permissions.
There are some user space network capabilities, but they are easily breaking, or discovered and in general not resilient to simple reboots.
This is one of the reasons you shouldn't leave your client 24/7 on.
It's true that in personal computers there might not be as much usage of users as in a multiuser computer or a server.
But without root access a virus wouldn't be able to affect system files, so it would have much less persistence and would be much easier for it to be removed, even automatically by some built in or third party antivirus.
Or, it might be possible to just remove it by making a separate user, and accessing the files of the older user from a folder.
In personal cellphones, also, there's heavy sandboxing, so in an OS like android, there would be a big difference betwen root and app compromise, if you don't get root you are only able to access the app data of the app you compromise.
Similar in Mac I think, but I'm not an expert, each app is isolated and a process from one app can only access its own data, escalating to root would allow affecting files of other apps.
But we are talking about containers, so in all likelihood this is about either servers or server developers, which make heavy use of separate users for even single use stuff like an HTTP server, whether manually or automatically, run 'apt/yum install apache2' and you'll see how it creates a separate user automatically.
With a user shell, I can grab their browser data, personal documents, and try to set up persistent background daemons that listen on programs and do keylogging/screenshotting (harder on Wayland than it was on X11).
With root, I can read all program memory, try to extract decryption keys for encrypted filesystems, modify the kernel, punch open backdoors, modify any arbitrary program, read all user files, etc.
A notable extra issue is the rise of AI agents, which often eagerly test the boundaries of every sandbox they are placed within. I would not run an AI agent as root, nor would I give it full access to a rootful container runtime.
The kinds of things that you list that an attacker could do with root access don't sound like things that an actual attacker would want if they are infiltrating random people's personal computers for their own gain. Modifying the kernel or arbitrary programs is so far beyond what typical malware tries to do that I think it seems kind of silly to consider those things when evaluating the security of an operating system designed for personal computers.
To me, they do sound like the kind of things an attacker would want, if they found a reliable, reproducible, automatable path to them. If I was writing malware, ransomware, or just exfiltrating data, I'd be much happier to have root access to do it. Even simple botnets, I'd probably want to try to replace a regular service that most everybody runs (like cupsd) with one that functions exactly like the real one, but also does the malicious activity, and similarly try to patch the package manager to persist it on updates.
The main risk is not that the agent breaks out of their sandbox, although it's an infitesimal possibility (that increases to certainty if you increase the token budget to 100M$ and use subagents to spend it all at once).
The main risk (for you, mere human without a 100M$ budget) is that it downloads a compromised package or vulnerability, or that it runs a stray rm -rf or some stupid stuff. A user provides reasonable protection, you don't NEED a vm (and even then that can be escaped).
Read up on basic user based security. Multiple users can exist on a system, each with its own resources, root/admin can effectively affect any user, so breaking the user-root barrier could allow a user to affect other users.
Originally users meant actual people, but in modern systems users can belong to subsystem, so for example an HTTP server with a website may have its own user, but a mail system could have another, so a breach in the website system would be confined to said user. Going from user to root is called a Local Privilege Escalation and would allow a breach from the website to metastasize into the mail system.
Yes, I really don't want to read about American politics when discussing operating systems and technology. It's already shoehorned into so many discussions that it no longer makes any sense.
A blog post talking about security but refusing to mention which operating was vulnerable to an exploit out of virtue signaling(?) is absurdist comedy.
If the author is referring to Omarchy, should we also stop using and mentioning Ruby on Rails? Preposterous.
I agree with your main point, and found it stupid that I had to search around to find what the hell was even being talked about directly. That said, the accusation of racism is about a Dane attending far-right British rallies, British anti-immigration protests, and saying things about deporting the populations of Muslims and Romani from Britain, Copenhagen, and Denmark. It doesn't make much sense to call the DHH racism issue "American politics".
In my opinion the biggest advantage of podman is that it uses pods with basically the same config and behavior as kubernetes does. As long as you just use podman pods instead (or possibly via) compose files you likely just notice that only the pod has one (and not any more) veth interface, that you reach other containers inside a pod via localhost:$port (instead of $service-name:$port) but when you switch later on to kubernetes you are already familiar with some basics.
Why would an adversary being able to execute code as root on a personal computer be a bigger threat than their being able to execute code as non-root? Surely just about any of the stuff that a malicious hacker might want to do to someone's personal computer can be done without root... right?
There are substantial differences.
For one, as non-root user you are tied to the permissions system and can't access most of the data. If one of your services (let's say sql) get hacked, they are tied to sql user, and unless the achieve privilege escalation, they can't mangle with other services data (eg webserver).
Also network wide, a non-root user can't use different protocol than tcp and udp. The only reason you can ping as a regular user is because of the setuid on the ping program, otherwise icmp is not allowed to non-root users.
There are of course other reasons, but these are some examples on how it would be different.
I think you're just illustrating my point. Those concerns don't apply to personal computers and they don't stop an intruder from doing anything they might practically want to do for gain. Like installing ransomware, participating in a botnet, exfiltrating personal files/browser cookies/etc (all accessible as non-root!), ...
I kind of think I am doing the opposite?
Apart from rootkit and backdoors that are more difficult to install as non-root, you cannot build specific tunnels as you don't have network permissions.
There are some user space network capabilities, but they are easily breaking, or discovered and in general not resilient to simple reboots. This is one of the reasons you shouldn't leave your client 24/7 on.
The difference is with root it’s easier to install further, more resident, malware
It's true that in personal computers there might not be as much usage of users as in a multiuser computer or a server.
But without root access a virus wouldn't be able to affect system files, so it would have much less persistence and would be much easier for it to be removed, even automatically by some built in or third party antivirus.
Or, it might be possible to just remove it by making a separate user, and accessing the files of the older user from a folder.
In personal cellphones, also, there's heavy sandboxing, so in an OS like android, there would be a big difference betwen root and app compromise, if you don't get root you are only able to access the app data of the app you compromise.
Similar in Mac I think, but I'm not an expert, each app is isolated and a process from one app can only access its own data, escalating to root would allow affecting files of other apps.
But we are talking about containers, so in all likelihood this is about either servers or server developers, which make heavy use of separate users for even single use stuff like an HTTP server, whether manually or automatically, run 'apt/yum install apache2' and you'll see how it creates a separate user automatically.
Yes, root still matters.
With a user shell, I can grab their browser data, personal documents, and try to set up persistent background daemons that listen on programs and do keylogging/screenshotting (harder on Wayland than it was on X11).
With root, I can read all program memory, try to extract decryption keys for encrypted filesystems, modify the kernel, punch open backdoors, modify any arbitrary program, read all user files, etc.
A notable extra issue is the rise of AI agents, which often eagerly test the boundaries of every sandbox they are placed within. I would not run an AI agent as root, nor would I give it full access to a rootful container runtime.
The kinds of things that you list that an attacker could do with root access don't sound like things that an actual attacker would want if they are infiltrating random people's personal computers for their own gain. Modifying the kernel or arbitrary programs is so far beyond what typical malware tries to do that I think it seems kind of silly to consider those things when evaluating the security of an operating system designed for personal computers.
To me, they do sound like the kind of things an attacker would want, if they found a reliable, reproducible, automatable path to them. If I was writing malware, ransomware, or just exfiltrating data, I'd be much happier to have root access to do it. Even simple botnets, I'd probably want to try to replace a regular service that most everybody runs (like cupsd) with one that functions exactly like the real one, but also does the malicious activity, and similarly try to patch the package manager to persist it on updates.
I run all agents as a different user for this reason.
My view is this isn't sufficent. They're pretty good at breaking out of stuff. A VM would be the minimal isolation boundary for me.
The main risk is not that the agent breaks out of their sandbox, although it's an infitesimal possibility (that increases to certainty if you increase the token budget to 100M$ and use subagents to spend it all at once).
The main risk (for you, mere human without a 100M$ budget) is that it downloads a compromised package or vulnerability, or that it runs a stray rm -rf or some stupid stuff. A user provides reasonable protection, you don't NEED a vm (and even then that can be escaped).
Code executed by user can do what user can do. What is the point you are trying to make?
Yes, of course there are still users out there that execute all software under the same account.
Inability to use the tools at hand to protect your data is not a technical issue.
No.
https://en.wikipedia.org/wiki/Time-sharing#Security
Read up on basic user based security. Multiple users can exist on a system, each with its own resources, root/admin can effectively affect any user, so breaking the user-root barrier could allow a user to affect other users.
Originally users meant actual people, but in modern systems users can belong to subsystem, so for example an HTTP server with a website may have its own user, but a mail system could have another, so a breach in the website system would be confined to said user. Going from user to root is called a Local Privilege Escalation and would allow a breach from the website to metastasize into the mail system.
>the one led by the racist, so it isn't getting a mention here
Are people really terminally online enough to understand this?
I'm pretty sure he's talking about Omarchy. They had some container related issue not too long ago.
OpenMandriva would be my next guess, but it's not a newer distro.
No, it's definitely a reference to the DHH/Romani drama from July and the Omarchy privilege escalation a few weeks back.
I don't know what he's referring to but I stopped reading at that sentence.
Yes, I really don't want to read about American politics when discussing operating systems and technology. It's already shoehorned into so many discussions that it no longer makes any sense.
A blog post talking about security but refusing to mention which operating was vulnerable to an exploit out of virtue signaling(?) is absurdist comedy.
If the author is referring to Omarchy, should we also stop using and mentioning Ruby on Rails? Preposterous.
I agree with your main point, and found it stupid that I had to search around to find what the hell was even being talked about directly. That said, the accusation of racism is about a Dane attending far-right British rallies, British anti-immigration protests, and saying things about deporting the populations of Muslims and Romani from Britain, Copenhagen, and Denmark. It doesn't make much sense to call the DHH racism issue "American politics".
>American politics
Is racism/aversion to it a uniquely American phenomenon?
I decided to read it at this one