If you refer to physical access I wouldn’t say that, I’ve encrypted partition.
But if you’re saying just access to my main user inside the OS, then I’d really like if you could elaborate with real examples how can user access do any harm to my system without root access. Real examples please not speculation or theory. Something I can run here right away to see by myself.
Your user account can run applications and read and write to a lot of locations on the disk.
So it can be used to run malware (cryptominers, ransomware, RATs etc.) Exfiltrate the data your account has access to, download or plant malicious or illegal data, use your internet connection to attack other systems with DOS or similar, use any logged in social media accounts to attack or spam your contacts, steal saved passwords and credentials from your web browsers, use your peripherals or connected devices (printers cameras microphone speakers), pivot to access other services on your local network (smart devices, IoT, TVs, home lab) etc.
There are comparatively few things an attacker wants on a desktop that actually require root access. It’s mostly just system files, package management and settings changes that require root to mess with. Eg. You would need root to dump a shadow file or stuff like luks encryption keys from kernel memory, but if an attacker has your logged in user account, the disk is already decrypted and account is already logged in.
Most systems also use single user, you normally give yourself docker group access (I use docker for work) and that alone is equivalent to root access. It’s not the 90s anymore where universities gave user access to all students, priv escalation was a big security threat, now it almost doesn’t mean anything, nobody shares the same machine anymore the way they used to do.
Yes kinda? It depends a lot on the system. It’s still pretty common, even with containers like docker, for different services to run with different accounts and permissions. Eg. If you have a webapp with a small database or something, the web server will be www-data or whatever and the db will be a different user account like a postgres user or something. Even a fresh Linux install will have a separate user account for things like ntp (or systemd-timesync) etc.
Users aren’t usually people, they’re daemons with limited scope and rule of least privilege.
Even if it’s all docker containers and you deploy them with the same docker account on the host, there are almost certainly a bunch of different accounts inside.
That way if there’s some vulnerability in ntp or something, an attacker might have permission to mess with the time but can’t, in theory, take over the whole container.
I think there is a trend towards caring less about that aspect of defence in depth if each service is in its own container and just rely on isolation. People are deploying services running as root with ansible or even just in dockerfiles, and not caring about it because there’s nothing else on the box for an attacker anyway. If they compromise the service, they’ve already got what they want.
I get the thought process but it still doesn’t feel good to me. If some docker bug shows up that allows a container user with root to break isolation and use the shared kernel to pivot to the host or other containers, then that one dodgy webapp that’s not running as a restricted user can become a part of a larger kill chain. It’s really easy to develop systems with least privilege in mind and there’s not much downside to doing it. It’s a good habit to to create different accounts for different services (even if there’s one admin/docker/ansible/whatever account for deployment).
If you refer to physical access I wouldn’t say that, I’ve encrypted partition.
But if you’re saying just access to my main user inside the OS, then I’d really like if you could elaborate with real examples how can user access do any harm to my system without root access. Real examples please not speculation or theory. Something I can run here right away to see by myself.
Your user account can run applications and read and write to a lot of locations on the disk.
So it can be used to run malware (cryptominers, ransomware, RATs etc.) Exfiltrate the data your account has access to, download or plant malicious or illegal data, use your internet connection to attack other systems with DOS or similar, use any logged in social media accounts to attack or spam your contacts, steal saved passwords and credentials from your web browsers, use your peripherals or connected devices (printers cameras microphone speakers), pivot to access other services on your local network (smart devices, IoT, TVs, home lab) etc.
There are comparatively few things an attacker wants on a desktop that actually require root access. It’s mostly just system files, package management and settings changes that require root to mess with. Eg. You would need root to dump a shadow file or stuff like luks encryption keys from kernel memory, but if an attacker has your logged in user account, the disk is already decrypted and account is already logged in.
Most systems also use single user, you normally give yourself docker group access (I use docker for work) and that alone is equivalent to root access. It’s not the 90s anymore where universities gave user access to all students, priv escalation was a big security threat, now it almost doesn’t mean anything, nobody shares the same machine anymore the way they used to do.
Yes kinda? It depends a lot on the system. It’s still pretty common, even with containers like docker, for different services to run with different accounts and permissions. Eg. If you have a webapp with a small database or something, the web server will be
www-dataor whatever and the db will be a different user account like apostgresuser or something. Even a fresh Linux install will have a separate user account for things likentp(orsystemd-timesync) etc. Users aren’t usually people, they’re daemons with limited scope and rule of least privilege.Even if it’s all docker containers and you deploy them with the same docker account on the host, there are almost certainly a bunch of different accounts inside.
That way if there’s some vulnerability in ntp or something, an attacker might have permission to mess with the time but can’t, in theory, take over the whole container.
I think there is a trend towards caring less about that aspect of defence in depth if each service is in its own container and just rely on isolation. People are deploying services running as root with ansible or even just in dockerfiles, and not caring about it because there’s nothing else on the box for an attacker anyway. If they compromise the service, they’ve already got what they want.
I get the thought process but it still doesn’t feel good to me. If some docker bug shows up that allows a container user with root to break isolation and use the shared kernel to pivot to the host or other containers, then that one dodgy webapp that’s not running as a restricted user can become a part of a larger kill chain. It’s really easy to develop systems with least privilege in mind and there’s not much downside to doing it. It’s a good habit to to create different accounts for different services (even if there’s one admin/docker/ansible/whatever account for deployment).
For me the scariest thing someone could do on my pc is exfiltrate all the data from my home directory which is readable by my user account.
Maybe I’m misunderstanding you, but that’s harm to me without root access.