9 ms·

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

by pram 2y ago

amelius 2y ago
Yeah, the threat model has shifted in recent years from other users to applications downloaded over the internet. It is a pity that OS security has not caught up.
Boogie_Man 2y ago
I often give myself stern talking tos when I made ignorant sysadmin decisions
- 0xbadcafebee 2y ago
  I put myself on a PIP for losing my backups. If I'm not careful I might fire my ass
quotemstr 2y ago
And that's why we should 1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and 2) configure polkit to allow the initial human user of the machine to elevate without typing a password. #2 is just a default, and special configurations can of course override it and return a configuration much like what we have today. But Jesus Christ Almighty Batman, if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password!
- monsieurbanana 2y ago
  Would biometrics that actually work solve the problem of the password for you? Because I'm not sure it's a good idea to not require passwords. At the very least it's a way to make people pause and ask themselves if they really want to give admin rights to whatever program they're running.
- dhosek 2y ago
  The problem is that any command that elevates privileges introduces a potential hacking vector so while having to enter your password or provide some other authentication at points where privileges get escalated is not an unreasonable ask.
  - quotemstr 2y ago
    A command running in my usual shell context can just change my dotfiles to do whatever it wanted anyway. There's little value these days in the traditional root-user separation. You don't actually need "admin rights" to do practically anything malware might want to do.
  - alwayslikethis 2y ago
    I don't think privilege escalation is a big concern on most personal systems. If you run any malicious code, even unprivileged, you're basically already screwed anyways since the code can access all of your home, upload it, delete/encrypt it, etc. https://xkcd.com/1200/ https://xkcd.com/1200/
  - tadfisher 2y ago
    No, the problem is that the command elevates privileges. Installing and running software should not be an admin-level operation, because its blast radius should be limited to data under the user account (at worst). Flatpak and other sandboxing technologies solves this for the most part.
- zoky 2y ago
  Sounds like an opaque, finicky, and non-portable solution to a relatively minor problem.
  - quotemstr 2y ago
    It's a major annoyance. The system knows perfectly well who I am. I shouldn't have to type my password repeatedly to do things the system knows I can do. The threat model no longer reflects the real world.
    - zoky 2y ago
      The system has no way of knowing who you are. It can’t tell if you’re really you, or just someone who walked by and started using your computer while you got up to go to the bathroom. If you really think the threat model is outdated, why not just run everything as root? Also, you know you can configure sudo to not ask you for a password, right? So why do you need to use a whole new framework and privilege model to basically save yourself from typing four letters?
      - quotemstr 2y ago
        The system does know who I am: the command is coming from me. An attacker doesn't need to elevate privileges to compromise me: he can steal whatever he needs without becoming root. He can replace sudo and steal my password too. The whole concept of my personal user account needing to elevate to root to make "system" changes is a relict of long-gone days of BBSes, shell accounts, and time sharing. These days, we should minimize friction between the user (almost always singular) and operation of his system. Apps, not users, should be sandboxed. I think this is another one of those paradigm shifts accomplished only after a lot of people retire.
        dizhn 2y ago
        Most distros already sort of elevate the initial users permissions so they can use sound, reboot without a password etc. So this is certainly doable. But doing it systemwise would also allow "rm -rf /" (which is specifically guarded nowadays I know). It's just an additional step. It's also why on most distros the prompt turns red when you're root. I don't have an opinion regarding if this is the right way. I have run as root in the past too. It's been mostly fine.
- varenc 2y ago
  You can turn off password checking on `sudo` completely. Shamefully, I have done this in some limited contexts.
- fsckboy 2y ago
  >if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password! I may be overgeneralizing, or I may not. I feel like people who hate retyping their passwords (it's most of people) are impatient people apt to take other shortcuts when they can, and therefore can't either be trusted with things like C pointers. Just don't take shortcuts, life's too short for shortcuts. I retype all my passwords all the time, and I don't let my browsers remember them either. It really doesn't bother me, and a side benefit is, I never forget my passwords.
II2II 2y ago
... and of those who have used multi-user Unix systems, very few would have had the privilege to use sudo in that context. (Unless you count managing a family computer, and even that is likely rare these days given that everyone seems to have their own machine.)
- codetrotter 2y ago
  I was member of a student union at my university, for people interested in computers. We had desktop computers and servers that belonged to the student union, and member students would eventually be granted sudo privileges if they had a reason to need it. When they gave me and my friends sudo privileges they told us basically the sudo lecture. Use it for good, don’t snoop in other students files, and be careful to not break stuff. They even had a real-life story of their own, about one past member that was kicked out of the union because he had used his sudo privileges to read solutions to an assignment from the home directory of another member! This wasn’t even that long ago. Around 2010. It was a nice student union.
don-code 2y ago
Indeed, I've been having this conversation with the junior engineers on my team. UNIX was designed for the days when computers - and the operating system - were shared resources, and each individual's permissions to it had to be strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance, especially where our applications in production are all single processes deployed in containers. But anyway, it at least gives them the context on why they're working on these projects to not make containers run as root.
- jorvi 2y ago
  > strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance Not so. Multiple users make perfect sense for a household tablet or a gaming PC / console shared between siblings. Concurrent access is rarely a thing anymore, but serial access is a very common use case.
  - weitendorf 2y ago
    These days if the device is expected to be ~always internet-connected (increasingly a safe bet) it probably makes more sense for both the developers and users to handle multiple users with a remote identity provider (email, individual account for the particular service, etc.) rather than implementing identity per-device. I'm pretty sure gaming consoles have had support for this for a long time (at least since xbox 360?), and Microsoft is moving towards this model with Windows. And Microsoft Active Directory is 25 years old. I personally find it annoying to be forced to use remote identity for devices used by me exclusively, but it makes a lot of sense for shared devices. I'm pretty sure a large portion of people sharing one kind of device would also using be using other devices for the same purpose (eg a kid with divorced parents, a school or office or library with laptops available to be checked out, a tablet used for logistics), so they'd want their data to sync across devices. Handling identity per-device works for local-only files, but also makes it so users need to manually and deliberately configure some kind of syncing if they really do want those files to be available across devices, which to technical people is NBD, but most users aren't technical. It's also just a more secure way to manage data in a corporate setting. Of course, not every shared device can be expected to always be connected to the internet, some people don't want to back things up remotely for a variety of reasons, and this doesn't matter as much for devices only used by one person. In practice I personally hate how much Microsoft begs and nudges you into this setup even if you're the only one using your computer. But for the majority of users in the majority of cases, remote identity is probably better than local identity, and in the absence of internet it can always fail-open to local identity.
weitendorf 2y ago
I think this is underrated as a design flaw for how Linux tends to be used in 2024. At its most benign it's an anachronism and potential source of complexity, as its worst it's a major source of security vulnerabilities and unintended behavior (eg linux multitenancy was designed for two people in the same lab sharing a server, not for running completely untrusted workloads at huge scale, so it doesn't really implement resource fairness or protect against DoS well). I haven't had a chance to try it out but this is why I think Talos linux (https://www.talos.dev/ https://www.talos.dev/) is a step in the right direction for Linux as it is used for cloud/servers. Though personally I think multitenancy esp. regarding containerized applications/cgroups is a bigger problem and I don't know if they're addressing that.
- mikepurvis 2y ago
  My impression was that all the hosted k8s providers are doing multitenancy with if not full per-customer VMs, at least additional abstractions like gVisor. Are there some that aren't? Or are you referring here more to untrusted/shared in the sense of platforms like Github Actions just running everyone's different loads on the same pool of kernels?
  - weitendorf 2y ago
    Right, I'm talking about shared-kernel multitenancy. Shared-kernel multitenancy isn't just about reducing the OS overhead from host + one or more VMs (or sandboxes) to just a single host, it's also about not having to continually start and stop virtual machines/sandboxes, which introduces its own resource overhead as well as a latency hit (which essentially always coincides with resource pressure from increased usage, since that's why you're scaling up) every time it's done. Also, even VMs and sandboxes don't really protect against DoS/resource fairness/noisy neighbor problems that well in many cases. Why does this matter? Incurring kernel/sandbox boot overhead on cold start/scaling makes it so that services have to over-provision resources to account for potential future resource needs. This wastes a lot of compute. I also think it's incredibly wasteful for companies to manage their own K8s cluster (if K8s supported multitenancy you'd probably want only one instance per-datacenter, and move whatever per-cluster settings people depend on to per-service. This is also much closer to "how Google does things" and why I think Kubernetes sucks to use compared to Borg), again because of all the stranded compute, and also because of the complexity of setting it up and managing it - but without shared-kernel multitenancy, multi-tenant K8s has to employ a lot of complicated workarounds in userspace. Or you can use a serverless product, ie pay for someone else's implementation of those workarounds, and still suffer some of the resource/latency overhead from lack of shared kernel multitenancy. This is one of the problems I want to address with my company BTW, but it would take years if not decades to get there, which is why I'm starting with something else.
throw0101d 2y ago
> It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me! Except if you're on a team of sysadmins running a fleet of systems, either a whole bunch of cattle and/or numerous pets. There are numerous occasions that I have to SSH to look at something on an individual system, and it's best practice to go in as yourself and then sudo-to-root if you need to poke into privileged parts. App folks can also be allowed in unprivileged and become the service users if needed. The fact that sudo can hook into LDAP also means we can centralize privilege escalations with groups and (particular) hosts. Lots of HPC out there as well that is multi-user.
- thousand_nights 2y ago
  > Except if you're on a team of sysadmins running a fleet of systems not trying to be rude but this doesn't sound like "most people"
  - Daneel_ 2y ago
    Interesting comment actually. I would have assumed that the vast majority of people using Linux are still sysadmins in small and large companies - this is certainly my personal experience. I wonder how many home users there are versus systems managed by sysadmins. I would still think there’s more in the corporate world, while I would think the opposite for Windows.
    - Swizec 2y ago
      > I wonder how many home users there are versus systems managed by sysadmins Isn’t Android the most popular Linux distro these days? Probably also most TV set-top boxes and other IoT devices
      - kelnos 2y ago
        And ironically an Android user (well, an Android user that uses the "official" OS image from the device's manufacturer) is not the system administrator of their phone/tablet, unless they essentially break into it, or install a different OS image designed to allow root access.
guappa 2y ago
Except if you've ever been to university or work with HPC or a number of other fields.
kube-system 2y ago
The vast majority of linux users use linux on a phone and have never opened a terminal. Most people who use 'sudo' in a terminal are professionals or academics who commonly do or have used linux in a multi-user environment.

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

by pram 2y ago

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

amelius 2y ago

Yeah, the threat model has shifted in recent years from other users to applications downloaded over the internet. It is a pity that OS security has not caught up.

Boogie_Man 2y ago

I often give myself stern talking tos when I made ignorant sysadmin decisions

0xbadcafebee 2y ago
I put myself on a PIP for losing my backups. If I'm not careful I might fire my ass

quotemstr 2y ago

And that's why we should 1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and 2) configure polkit to allow the initial human user of the machine to elevate without typing a password. #2 is just a default, and special configurations can of course override it and return a configuration much like what we have today. But Jesus Christ Almighty Batman, if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password!

monsieurbanana 2y ago
Would biometrics that actually work solve the problem of the password for you? Because I'm not sure it's a good idea to not require passwords. At the very least it's a way to make people pause and ask themselves if they really want to give admin rights to whatever program they're running.
dhosek 2y ago
The problem is that any command that elevates privileges introduces a potential hacking vector so while having to enter your password or provide some other authentication at points where privileges get escalated is not an unreasonable ask.
- quotemstr 2y ago
  A command running in my usual shell context can just change my dotfiles to do whatever it wanted anyway. There's little value these days in the traditional root-user separation. You don't actually need "admin rights" to do practically anything malware might want to do.
- alwayslikethis 2y ago
  I don't think privilege escalation is a big concern on most personal systems. If you run any malicious code, even unprivileged, you're basically already screwed anyways since the code can access all of your home, upload it, delete/encrypt it, etc. https://xkcd.com/1200/ https://xkcd.com/1200/
- tadfisher 2y ago
  No, the problem is that the command elevates privileges. Installing and running software should not be an admin-level operation, because its blast radius should be limited to data under the user account (at worst). Flatpak and other sandboxing technologies solves this for the most part.
zoky 2y ago
Sounds like an opaque, finicky, and non-portable solution to a relatively minor problem.
- quotemstr 2y ago
  It's a major annoyance. The system knows perfectly well who I am. I shouldn't have to type my password repeatedly to do things the system knows I can do. The threat model no longer reflects the real world.
  - zoky 2y ago
    The system has no way of knowing who you are. It can’t tell if you’re really you, or just someone who walked by and started using your computer while you got up to go to the bathroom. If you really think the threat model is outdated, why not just run everything as root? Also, you know you can configure sudo to not ask you for a password, right? So why do you need to use a whole new framework and privilege model to basically save yourself from typing four letters?
    - quotemstr 2y ago
      The system does know who I am: the command is coming from me. An attacker doesn't need to elevate privileges to compromise me: he can steal whatever he needs without becoming root. He can replace sudo and steal my password too. The whole concept of my personal user account needing to elevate to root to make "system" changes is a relict of long-gone days of BBSes, shell accounts, and time sharing. These days, we should minimize friction between the user (almost always singular) and operation of his system. Apps, not users, should be sandboxed. I think this is another one of those paradigm shifts accomplished only after a lot of people retire.
      - dizhn 2y ago
        Most distros already sort of elevate the initial users permissions so they can use sound, reboot without a password etc. So this is certainly doable. But doing it systemwise would also allow "rm -rf /" (which is specifically guarded nowadays I know). It's just an additional step. It's also why on most distros the prompt turns red when you're root. I don't have an opinion regarding if this is the right way. I have run as root in the past too. It's been mostly fine.
varenc 2y ago
You can turn off password checking on `sudo` completely. Shamefully, I have done this in some limited contexts.
fsckboy 2y ago
>if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password! I may be overgeneralizing, or I may not. I feel like people who hate retyping their passwords (it's most of people) are impatient people apt to take other shortcuts when they can, and therefore can't either be trusted with things like C pointers. Just don't take shortcuts, life's too short for shortcuts. I retype all my passwords all the time, and I don't let my browsers remember them either. It really doesn't bother me, and a side benefit is, I never forget my passwords.

II2II 2y ago

... and of those who have used multi-user Unix systems, very few would have had the privilege to use sudo in that context. (Unless you count managing a family computer, and even that is likely rare these days given that everyone seems to have their own machine.)

codetrotter 2y ago
I was member of a student union at my university, for people interested in computers. We had desktop computers and servers that belonged to the student union, and member students would eventually be granted sudo privileges if they had a reason to need it. When they gave me and my friends sudo privileges they told us basically the sudo lecture. Use it for good, don’t snoop in other students files, and be careful to not break stuff. They even had a real-life story of their own, about one past member that was kicked out of the union because he had used his sudo privileges to read solutions to an assignment from the home directory of another member! This wasn’t even that long ago. Around 2010. It was a nice student union.

don-code 2y ago

Indeed, I've been having this conversation with the junior engineers on my team. UNIX was designed for the days when computers - and the operating system - were shared resources, and each individual's permissions to it had to be strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance, especially where our applications in production are all single processes deployed in containers. But anyway, it at least gives them the context on why they're working on these projects to not make containers run as root.

jorvi 2y ago
> strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance Not so. Multiple users make perfect sense for a household tablet or a gaming PC / console shared between siblings. Concurrent access is rarely a thing anymore, but serial access is a very common use case.
- weitendorf 2y ago
  These days if the device is expected to be ~always internet-connected (increasingly a safe bet) it probably makes more sense for both the developers and users to handle multiple users with a remote identity provider (email, individual account for the particular service, etc.) rather than implementing identity per-device. I'm pretty sure gaming consoles have had support for this for a long time (at least since xbox 360?), and Microsoft is moving towards this model with Windows. And Microsoft Active Directory is 25 years old. I personally find it annoying to be forced to use remote identity for devices used by me exclusively, but it makes a lot of sense for shared devices. I'm pretty sure a large portion of people sharing one kind of device would also using be using other devices for the same purpose (eg a kid with divorced parents, a school or office or library with laptops available to be checked out, a tablet used for logistics), so they'd want their data to sync across devices. Handling identity per-device works for local-only files, but also makes it so users need to manually and deliberately configure some kind of syncing if they really do want those files to be available across devices, which to technical people is NBD, but most users aren't technical. It's also just a more secure way to manage data in a corporate setting. Of course, not every shared device can be expected to always be connected to the internet, some people don't want to back things up remotely for a variety of reasons, and this doesn't matter as much for devices only used by one person. In practice I personally hate how much Microsoft begs and nudges you into this setup even if you're the only one using your computer. But for the majority of users in the majority of cases, remote identity is probably better than local identity, and in the absence of internet it can always fail-open to local identity.

weitendorf 2y ago

I think this is underrated as a design flaw for how Linux tends to be used in 2024. At its most benign it's an anachronism and potential source of complexity, as its worst it's a major source of security vulnerabilities and unintended behavior (eg linux multitenancy was designed for two people in the same lab sharing a server, not for running completely untrusted workloads at huge scale, so it doesn't really implement resource fairness or protect against DoS well). I haven't had a chance to try it out but this is why I think Talos linux (https://www.talos.dev/ https://www.talos.dev/) is a step in the right direction for Linux as it is used for cloud/servers. Though personally I think multitenancy esp. regarding containerized applications/cgroups is a bigger problem and I don't know if they're addressing that.

mikepurvis 2y ago
My impression was that all the hosted k8s providers are doing multitenancy with if not full per-customer VMs, at least additional abstractions like gVisor. Are there some that aren't? Or are you referring here more to untrusted/shared in the sense of platforms like Github Actions just running everyone's different loads on the same pool of kernels?
- weitendorf 2y ago
  Right, I'm talking about shared-kernel multitenancy. Shared-kernel multitenancy isn't just about reducing the OS overhead from host + one or more VMs (or sandboxes) to just a single host, it's also about not having to continually start and stop virtual machines/sandboxes, which introduces its own resource overhead as well as a latency hit (which essentially always coincides with resource pressure from increased usage, since that's why you're scaling up) every time it's done. Also, even VMs and sandboxes don't really protect against DoS/resource fairness/noisy neighbor problems that well in many cases. Why does this matter? Incurring kernel/sandbox boot overhead on cold start/scaling makes it so that services have to over-provision resources to account for potential future resource needs. This wastes a lot of compute. I also think it's incredibly wasteful for companies to manage their own K8s cluster (if K8s supported multitenancy you'd probably want only one instance per-datacenter, and move whatever per-cluster settings people depend on to per-service. This is also much closer to "how Google does things" and why I think Kubernetes sucks to use compared to Borg), again because of all the stranded compute, and also because of the complexity of setting it up and managing it - but without shared-kernel multitenancy, multi-tenant K8s has to employ a lot of complicated workarounds in userspace. Or you can use a serverless product, ie pay for someone else's implementation of those workarounds, and still suffer some of the resource/latency overhead from lack of shared kernel multitenancy. This is one of the problems I want to address with my company BTW, but it would take years if not decades to get there, which is why I'm starting with something else.

throw0101d 2y ago

> It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me! Except if you're on a team of sysadmins running a fleet of systems, either a whole bunch of cattle and/or numerous pets. There are numerous occasions that I have to SSH to look at something on an individual system, and it's best practice to go in as yourself and then sudo-to-root if you need to poke into privileged parts. App folks can also be allowed in unprivileged and become the service users if needed. The fact that sudo can hook into LDAP also means we can centralize privilege escalations with groups and (particular) hosts. Lots of HPC out there as well that is multi-user.

thousand_nights 2y ago
> Except if you're on a team of sysadmins running a fleet of systems not trying to be rude but this doesn't sound like "most people"
- Daneel_ 2y ago
  Interesting comment actually. I would have assumed that the vast majority of people using Linux are still sysadmins in small and large companies - this is certainly my personal experience. I wonder how many home users there are versus systems managed by sysadmins. I would still think there’s more in the corporate world, while I would think the opposite for Windows.
  - Swizec 2y ago
    > I wonder how many home users there are versus systems managed by sysadmins Isn’t Android the most popular Linux distro these days? Probably also most TV set-top boxes and other IoT devices
    - kelnos 2y ago
      And ironically an Android user (well, an Android user that uses the "official" OS image from the device's manufacturer) is not the system administrator of their phone/tablet, unless they essentially break into it, or install a different OS image designed to allow root access.

guappa 2y ago

Except if you've ever been to university or work with HPC or a number of other fields.

kube-system 2y ago

The vast majority of linux users use linux on a phone and have never opened a terminal. Most people who use 'sudo' in a terminal are professionals or academics who commonly do or have used linux in a multi-user environment.