Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When was the famous "sudo warning" introduced? (2019)

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

21–30 of 180 posts

Re: When was the famous "sudo warning" introduced? (2019)

#21

Post by mikepurvis »

weitendorf wrote: post #20
pram wrote: post #3

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!

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 implemen…

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?

Re: When was the famous "sudo warning" introduced? (2019)

#22

Post by throw0101d »

pram wrote: post #3

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!

> 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.

Re: When was the famous "sudo warning" introduced? (2019)

#23

Post by quotemstr »

zoky wrote: post #14
quotemstr wrote: post #5

Earlier quoted context omitted.

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. Bu…

Sounds like an opaque, finicky, and non-portable solution to a relatively minor problem.

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.

Re: When was the famous "sudo warning" introduced? (2019)

#24

Post by weitendorf »

jorvi wrote: post #19
don-code wrote: post #11

Earlier quoted context omitted.

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 conta…

> 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.

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.

Re: When was the famous "sudo warning" introduced? (2019)

#25

Post by thousand_nights »

throw0101d wrote: post #22
pram wrote: post #3

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!

> 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…

> 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"

Re: When was the famous "sudo warning" introduced? (2019)

#26

Post by zoky »

quotemstr wrote: post #23
zoky wrote: post #14

Earlier quoted context omitted.

Sounds like an opaque, finicky, and non-portable solution to a relatively minor problem.

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.

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?

Re: When was the famous "sudo warning" introduced? (2019)

#27

Post by Daneel_ »

thousand_nights wrote: post #25
throw0101d wrote: post #22

Earlier quoted context omitted.

> 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…

> 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"

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.

Re: When was the famous "sudo warning" introduced? (2019)

#28

Post by horeszko »

ggm wrote: post #16

Back in the 90s we were told ostentatiously to include "unauthorised access is not permitted" to the login prompt. Why? Because the login prompt said "please login:" and this was being read by some bush lawyer as an invitation to connect, and therefore would impede a case if we had a hacker login with a stolen password. I think it was founded on urban myth, but I assure you this is what we were told to do: add text t…

My networking instructor still suggests this today when configuring the login for routers and switches

Re: When was the famous "sudo warning" introduced? (2019)

#29

Post by weitendorf »

mikepurvis wrote: post #21
weitendorf wrote: post #20

Earlier quoted context omitted.

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 implemen…

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?

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.

Re: When was the famous "sudo warning" introduced? (2019)

#30

Post by 3eb7988a1663 »

weitendorf wrote: post #20
pram wrote: post #3

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!

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 implemen…

Actually, I have been wondering if using a Linux system as multi-user could be a boon in security.

As single user, each and every process has full and complete control of $HOME. Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. Without going full QubeOS, get some amount of application separation so my photo utility does not have permissions to read ~.ssh.

Create a user account for each application (Firefox, Email, PDFReader, etc). Run each of those applications as the foreign user account. Each application now has its own $HOME with minimal user data. Barring a root-escalation or user-separation bug, the data in your true HOME should be isolated. Even process/environment variable space should be segregated.

This also has a win in that it becomes possible to better segregate the threat model of less trusted applications. Doing granular network permissions per application is a bit hairy in Linux, but it is trivial to fully deny network access to a specific user account.

Not true isolation, but for the semi-trusted development environment, gets you a little something.

Post reply on HN