Doesn't Linux have one of these CVEs...each week?
Doesn't Linux have one of these CVEs...each week?
Ignorance is bliss! Simply use docker in its (old) default setup, instead of podman, apptainer, docker-rootless ... and that world is yours.
Added bonuses are the incredible stupid integration with ufw on Ubuntu, images with laughable uid mapping, ...
How that shit got traction baffles me.
And that’s exactly how any reputable image would be built.
But nobody mentioned Linux. There's no need for whataboutism. They both shouldn't have these vulnerabilities.
Why would a target executable use sudo? There are proper mechanisms for automated elevation of permissions and sudo isn’t it.
sudo is designed for user interactivity. And by default prompts for a password. However some people get lazy and disable the password entry requirement.
An attacker will probably just use the host for sending spam emails, bot / DDoS traffic or look for other daemons they can jump to which weren’t web accessible (eg a database).
And furthermore, if you’ve got a RCE in a daemon then that code is the running as the daemons’ user. Which shouldn’t be in the sudoers file (eg wheel group) to begin with.
Nope! Just alias sudo to something that logs the password.
For what it’s worth, Windows’ security model says it’s not an exploit that programs can grant themselves admin rights if the user is an admin (https://github.com/hfiref0x/UACME). But afaik Linux doesn’t have that model so it is a bit of an issue that this is possible
It’s not possible. At least not unless those users have already borked their own system.
The previous poster was clutching at straws.
You’ve shifted goal posts to now talk about desktop applications when the topic was originally about daemons
You imagined that. The topic was never originally about daemons.
> A local privilege escalation to root via an exploitable service?
> Doesn't Linux have one of these CVEs...each week?
Why else would people be talking about docker, and user/group ownership of running services, and so on and so forth, in response to their comment and yours?
- “Windows Defender” is the service
- the discussion was about how Defender might have “root” access but Linux services have CVEs too.
The reason Defender has elevated access is precisely because it needs to do stuff like hook into file system events and scan files irrespective of their underlying ACLs.
So it’s not the same as desktop anpplication exploit that would be running as the same user/group as the person logged in. And it’s also not the same as any other type of service, be that a RDBMS, web server, IRC server, nor any other type of server you might think off.
In fact this is true for both Windows AND Linux. Your average service will not have access to read user files and desktop applications are not services running as root.
I get you’re trying to make a balanced argument. And I do agree that Linux has had a great many poorly thought out design decisions (and even more problems inherent from its POSIX lineage). But the specific arguments you’re making in this thread are just misinformed and misunderstand how these operating systems work.
Like I said before, your RCE exploit will be running as the user and group of the service you exploited. For example www:www
So you’re not going to be able to write into Joe Bloggs .bashrc file unless Joe was stupid enough to enable write permission to “other”. Which, once again, requires the user to purposely modify the system into being less secure than its default configuration
Only if the exploit is through a web server or similar. If it's through the user's web browser, email client, video player, etc. etc. then you'll have write access to their home directory.
Yes, if a desktop application has a bug then it can do damage. But at that point, who cares about sudo? The exploit already has access to your ssh keys, browser cookies and history (so can access banking and shopping sites), crypto-currency wallets and so on and so forth.
What an exploit has access to here is so much worse than getting root access on a desktop OS.