When was the famous "sudo warning" introduced? (2019) | Hacker News Reader

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

retrocomputing.stackexchange.com

158 pointsBoogie_Man176 comments

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 to make it plain, the invitation was to legitemate users only.

I felt the sudo warning was in the same spirit.

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

Perhaps it is useful for countries that still don't have any real computer crime laws? Because in most western nations it would be totally pointless.

No, the US is the main country that loves these messages. Have you seen the size of universities or the government ? It's just clerical staff doing make believe work. Go to any .gov website. They'll throw up a wall of bs before you log in (e.g., https://ttp.dhs.gov/ ).

Sounds like you have never been to Europe. Here they make you actually sign (as in pen and paper) this stuff before they give you access.

I used to read an Eastern European world traveler photoblogger who’d been to damn near every country (even a lot that most folks from even semi-developed countries would consider far too dangerous or boring to be worth going out of your way to visit—he’d surely been to at least 150 countries, several more than once) and according to him the specific behavior of posting regulations and signs all over the place is practiced nowhere as much as the US, with only Australia coming sort-of close.

I was a bit blind to it, being a born American, but once he pointed it out I can’t un-see it. The land of the free really does love posting regulations everywhere.

It's the sort of cultural blindness that comes with not being able to read the native languages in all 150 countries this person's claimed to have visited.

Once you're able to read a new language, you see all kinds of new signs, especially when you visit a new country.

It's like how people who only read English think of Japan as some kind of blissful artspace, when the reality is that it is far more overloaded with ads than Western countries. Your mind just processes it as abstractions because you can't read the language.

> in all 150 countries this person's claimed to have visited.

They had mountains of boring photos of traffic signs and fire hydrants and bollards and normal people on the street and in other public spaces living their lives and that kind of stuff in lots of countries, so I'm fairly sure they had been to them. :-)

I don't think their take was a result of blindness to languages they don't/didn't know—we really do seem remarkably keen on posting lots of regulations and restrictions at the entrance to every-damn-place, which I've noticed since he pointed it out. Other places may have those restrictions and one may well find a variety of laws and norms enforced in any of several ways in places with less regulation-posting, should one violate them—they're just (I gather—my own limited traveling supports his take, but I've only been to a few other countries) usually not quite as obsessed with posting lots of notices about regulations on every flat surface where strictly-public spaces meet slightly-less-public or private spaces. Since having it pointed out, I've noticed that I'm (when not thinking about it) ignoring a bunch of notices akin to a click-through EULA when just entering stores, and it's not hard for me to believe that lots and lots of places get by just fine, and not necessarily with fewer de jure and de facto restrictions on behavior, with far less posting of notices about those restrictions. Clearly it's not terribly necessary since I'm pretty sure most of us hardly pay any attention to it.

While I'm not familiar with the particular blogger of which you speak, I'm always skeptical about travel bloggers who claim to have been in an incredible number of places.

I say this because it's very easy to hire someone on the other side of the planet to take a series of digital photos of their lives and tourist attractions for a week or so and then you, yourself, post a travel blog with their content. Because of exchange rates, often the more exotic the location, the cheaper it is. Sometimes incredibly cheap. Like $20 to some far-off rando can reap thousands in Google Ads for a web site.

I know because I used to do this for an American travel company way back in 2015-ish. Back then, I'd often hire cab drivers to do it because they always had a camera phone with them, and they were always going to airports and restaurants and tourist places and standing around with time to kill anyway.

Back then it would be weird to have a picture of yourself in a travel blog, but since everyone is a narcissist these days, you'd have to Photoshop or AI yourself into the photos and videos to be believable, but that's trivial now.

Again, I'm not saying your guy is a big faker. I'm just saying there are big fakers out there, so be careful who you believe.

With so much of the focus on differences between fire hydrants and street signs in different countries, the direct appeal was niche and the side-appeal that his very light and only occasional commentary on the photos was sometimes interesting, so that seems too indirect to possibly work as a way to catch a money-making amount of readership. This was tail-end-of-the-early-Web sort of stuff, started a few years before the rise of the contracted out ("Four-hour workweek" sorts trying to jumpstart that kind of "hustle", at least in the early days) monetized fake blog.

There was no pitch, and no ads, no self-promotion and barely any personal background at all, it was just "here's a crappy plain list of places I've been that breaks in surprising ways if JS is disabled" and if you clicked the links you'd get some broken-English (sometimes... other times you'll have to get out Google Translate) light commentary on photos he took there, though often there'd be several photos in a row with no commentary aside from maybe basic labels like "a bollard in [city]", that break down as about:

- 30% fire hydrants,

- 20% street signs or other road markers or traffic control devices,

- 20% bollards,

- 5% adaptive architectural details in very-cold or otherwise out of the ordinary environments

- 5% photos of the above things but specifically highlighting how much worse leftover French colonial infrastructure tends to be than British,

- 3% dudes shitting on beaches

- 2% disgusting illegal open air dumps, often on Pacific island "paradises" since I guess they're just covered in such things almost anywhere that's not a tourist hot-spot, which made a ton of sense in hindsight once pointed out—very limited space, lots of goods coming in, not rich enough to send the trash somewhere else, so of course that's a problem,

- nearly 0% any photos of normal landmarks or attractions you'd expect a tourist to take,

and 15% all else, usually observations of drug-related cafe culture stuff (I had no idea there were so many locally-tolerated-and-widely-openly-used but barely-known-to-Americans drugs out there before browsing that blog, often some kind of chewable leafy product or another), non-fancy food, whatever rusty barely-working ancient rural motorized mass transportation he'd ended up on this time, or slice-of-life observational things like a little "movie theater" in a very poor city that's some folding chairs in a little room with a smallish CRT TV and a DVD player at the front and a guy taking money at the doorless entry doorway (or dudes shitting on beaches, already covered separately because it featured weirdly often). Quite a bit of coverage of how shitty planned cities almost always are, and why (too much focus on big, wide roads that don't really need to be that big or wide, with huge unusable green spaces making them even worse, all in the name of getting big impressive sight lines on a few scattered monuments and buildings—this ties into the "place vs. non-place" concept I've seen used to criticize similar types of vision-first and "green space" obsessed city planning on other parts of the Web)

Like, the extreme focus on details most people wouldn't think to take a photo of and that are also kinda boring to nearly everyone convinced me the dude's angle was just that he... found comparing minor but common features of fundamental infrastructure more interesting than most people. When he had photos of anything but that sort of thing, it was more of an afterthought or accident, it seemed like. Plus there weren't even any ads or attempts to promote himself or products.

The European way is to post a gigantic wall of text like 1.5 by 1.5 meters with small letters and a full binding contract somewhere close to the entrance.

All US parking garages have exactly that and it's so weird. Nobody reads them (what, from your car before paying and entering? LOL, nobody even reads the smaller notices attached to the payment machines, nor half the text the displays print during an interaction) so all the work at writing, printing, and posting them is just a kind of weird secular-religion ritual.

Now imagine it's everywhere. Entering a mall? You bet it's long. Entering a post office, bank, government agency? Of course. Entering a barber, restaurant, bar? Yep, even there. Entering a residential building? Yes, the inhabitants actually have a contract about their co-living and how they and others should behave in the common areas.

This translates to ecommerce too - check out the terms of service and privacy policies of some European web shops.

The US does it, too, but it's often separate sheets of printed paper and a few standard-issue laminated posters. Plus a few briefer notices posted to the doors, especially at larger businesses.

It's possible EU states have gotten worse ("worse"—I mean, it's basically harmless, which is why it just fades into the background and it's easy to not even notice it, aside from that the whole thing's a little bit of wasted work) about this since his writing and since I've been there, as the latest of his posts I read were probably from travel in the late '00s, and I haven't been to any part of Europe myself since not long after that.

This has definitely been the case since early 90s all around Eastern Europe. I grew up there. Maybe he didn't notice - these walls of text are close to the entrance but definitely not the most highlighted feature there. I'd guess many locals don't even know - it's just that I like to read random stuff.

I haven’t seen this in my country (I live in the country of Europe).

I believe you didn't see it, many locals didn't. But I bet you can find it if you go looking. I personally check this stuff, it's my kind of weirdness, and I assure you it's the case in every EU country (I checked) and I'd bet it's the case in every European country.

Europe has its own version of this nonsense (GDPR cookie banners), but that stems from a different misguided belief. Europe believes that banners can affect markets. The US believes that banners can affect the law. Both are wrong.

>Both are wrong.

What are 'GDPR cookie banners' [possessive, as in GDPR mandates them? And, what is the 'a different misguided belief...that can affect markets'?

GDPR demands consent, which naturally means a blocking modal that needs to be answered before any interaction is possible.

The misguided belief is that this is going to stop people from clicking on "accept".

But it seems unnecessary given the existence of its laws. For example, CFAA makes unauthorized use of a computer system illegal regardless of whether the system communicates it. Perhaps these messages originated prior to the CFAA, in which case perhaps they were necessary back then, and nobody has dared to remove them.

This is unlike trespassing in the US, however, which does require informing the person (written in a conspicuous location, or direct verbal conversation) they are unwelcome on whatever land they began accessing, and allowing them to promptly retreat, before any violation is committed. Access is generally permitted (e.g., to allow for unsolicited deliveries) prior to such communication.

There are other legitimate reasons:

1. contractual obligations, with a lower burden of proof than criminal cases, and different remedies

2. helpful reminders

It's as useful as people that say they are not lawyers when commenting online.

My views and opinions are, in fact, those of my employer.

It's always true if you're self-employed!

You underestimate my capacity for cognitive dissonance.

Or my personal favorite, people who upload videos to youtube with the disclaimer "I don't own this video". I have no idea how that meme took hold, or how those people don't realize that it makes it worse for you if you admit to knowingly infringing copyright.

It is the mistaken belief that copyright simply protects the author's credit or attribution. Likely by people who drew their entire understanding of copyright from their schoolteachers' disapproval of plagiarism.

It would keep lawyers out.

I did a similar thing once (off my own back - I was young and naive) on a dead simple web app I wrote. I put a footer that said something like "all access is logged, unauthorised access will be investigated" with the current IP address to try to demonstrate that I had the data to do it. I didn't. And nothing of the sort was logged or investigated. I just hoped it would put people off!

As a kid I saw a sign going into the bathroom at Sears that said "prohibited behavior not allowed". I had to ask my mom what prohibited meant and was quite surprised when she explained that it means "not allowed".

Love it! I've seen a lot of signs like, "prohibited items are not allowed in facility." Especially TSA signs at the airport which also include guns and knives and such in big red circles with lines through them. I always wonder if those signs were made by a brilliant low-grade troll or not.

I once added text that said, "Unauthorized access is not authorized" as a low-grade troll, and people liked it so it stayed

You can think of “Prohibited items” as a variable which happens to be called like that for clarity. It’s a clearly defined arbitrary list and it’s referred as such in any relevant text. The prohibition starts at an arbitrary point in the building so they reference the variable when communicating this to you.

No Spitting. The Mgt.

"The Midget."

Similar feeling with "No trespassing"... like, duh!

We had a client insist that the SSH prompt be changed to include a half-page rambling about it being an "proprietary system" and "access prohibited for non-authorized users", something like that. Failing to include their specific wording, when we did their new staging setup, was a critical, must fix now bug.

Their argumentation was that it was a regulatory requirement and would allow for prosecution.

This is a regular sight when accessing a US government computer system. Even managing things like Global Entry come with such a warning.

These types of messages largely stem from NIST 800-171 (and related standards). Specifically NIST 800-171 has the control "Display a system use notification message with privacy and security notices consistent with applicable CUI [controlled unclassified information] rules before granting access to the system." So it is very common when dealing with companies that are government contractors or subcontractors. 800-171 also sometimes gets used as a security framework even when not dealing with the government so these requirements sometimes end up outside those contexts as well.

This is like the warning in emails about "not reading it if you aren't supposed to have received it" like yeah sure how do you know it's not for you then.

Until someone can provide a link to an actual case where that's mattered, I refuse to believe that those have any real legal power.

I love those 12-line long warnings when someone posts to an open email list.

For anyone else who hasn't heard it before, a bush lawyer is "One who is not qualified in law yet attempts to expound on legal matters."

https://en.m.wiktionary.org/wiki/bush_lawyer

thankfully the negative use of bush in the context of "bush lawyer" does not extend into the use of bush in "bush pilot"

Perhaps "bush lawyer" was the inspiration for "hedge wizard."

https://www.reddit.com/r/DnD/comments/zetwkt/what_exactly_is...

The most-promising thread I’ve pulled at for this after a few searches is that this all (hedge wizard, hedge witch) derives from “hedge school”, with either “hedge witch” or “hedge wizard” being the first of this form, and later uses of those and related terms (like Martin’s “hedge knight”) deriving from these derivatives, incorporating meaning and context not necessarily intended by the original formulation, for reason of not realizing the specific original reason for labeling them “hedge” (the association with unofficial, unorthodox, and maybe illegal schooling)

https://en.m.wikipedia.org/wiki/Hedge_school

TIL, this was my first time seeing the term. I just assumed that the poster had left out the second word of "bush league". That would mean something similar but subtly different, though (a lawyer not up to professional standards).

I'd imagine both terms are derogatory, no? "Bush" is usually a derogitroy descriptor of aboriginal peoples as "primitive" or "unsophisticated"

The subtle difference is not that one is neutral. It's that "bush league lawyer" is a bad lawyer, but "bush lawyer" can be either that or someone attempting to act as a lawyer without actually being one.

I've heard a similar formulation of "barracks lawyer" from military folks. The dude who gives terrible advice but can use enough legal jargon to make it sound convincing.

Reminds me of those signs on the interstate pass throughs that connect one side to the other, that cops often sit on. The sign says something like "authorized vehicles only" because presumably every one needing to turn around would use them to u-turn on the interstate, which is likely considered to not be safe. I used one to turn around one time and when called out by my kid, I assured him that I was authorized. I have no idea who is actually authorized to use those, outside of emergency vehicles.

It's interesting how messages gets their own life.

I was building a user-impersonation system, and it allowed a power-admin to login as another user to change their settings and to help them.

When you signed in as the user it said:

> You are now signed in as User\##{user_id}, behave nicely ;-)

and when you switched back to your admin it said:

> You are now signed back in as Admin\##{admin_id}, wreak havoc! ;-)

I met with a former colleague years later, and he still referred to the wreak havoc message that I didn't think about for more than 10 seconds, but I had installed that in his brain and it lived there as a memory of that company and that system.

You infected him with a mind virus. He's going to tell about that message to other people, who will tell about it to others. Before you know it, it's gone viral.

Oh. It sounds like you were The Bastard Operator From Hell: https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell

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 often give myself stern talking tos when I made ignorant sysadmin decisions

I put myself on a PIP for losing my backups. If I'm not careful I might fire my ass

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!

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.

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.

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/

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.

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.

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?

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.

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.

Your first paragraph is obviously wrong, so maybe dial back the pronouncements.

What you are advocating for was a disaster for Windows, btw.

> dial back the pronouncements.

No. Maybe have an argument instead of pointing and shrieking?

> What you are advocating for was a disaster for Windows, btw.

No it wasn't. I think UAC is a waste of time, but the type-your-password-into-sudo camp is advocating something strictly worse than UAC.

I don't need to type my god damned password to install a program on iOS or Android.

Moving validation to an app store is doable but it’s very costly and not a complete solution. Sandboxing is here. Multiple layers is generally better, and you can configure your system as you see fit.

Okay, then just NOPASSWD yourself?

I've always had issues with nopasswd, maybe it's just a thing with how I'm doing it but it never seems to work in Arch

I vaguely remember having issues with it at one point - I wonder if having a non-NOPASSWD group setting overrides a NOPASSWD user setting?

Maybe make sure there's only a single sudoers entry that applies to your user, and that single entry is NOPASSWD.

I've personally never had issues with it on Arch; I agree with the sibling comment that some issue with groups might be the the issue. In case it helps, here's what I always do to set it up on a new installation:

1. Install `sudo` via pacman 2. Optionally set the EDITOR env var to use something other than vi for the following command, e.g. `export EDITOR=nvim` (if you do change it and want to retain the default shortcuts like `ctrl+a` to go to the beginning of the line, you'll also probably want to do `set -o emacs` to make sure it doesn't get changed due to the EDITOR being set) 3. Run `sudo visudo` (or `sudo -E visudo` if you want to make sure the `EDITOR` env var is used) to edit the sudoers file and look for the line `%wheel ALL=(ALL:ALL) NOPASSWD: ALL`. Uncomment that one, and comment out the one slightly above that's the same but doesn't have `NOPASSWD`. Save and exit the editor. 4. If you're not already a member of the `wheel` group, add yourself with `usermod -aG wheel <your username>`. You might need to log out and back in or reboot to this to take effect; groups are often weird like that.

As an alternative, Arch has `opendoas` in the `extra` repos nowadays, which is a port of the OpenBSD replacement for sudo designed to be easier to configure. There's literally no configuration for it by default, and to enable passwordless, all you need to put in `/etc/opendoas.conf` is `permit nopass :wheel`.

You can turn off password checking on `sudo` completely. Shamefully, I have done this in some limited contexts.

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

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

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.

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.

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

Remote identity only works well when paired with cloud storage; otherwise, you have a recipe for confusion. It works for game consoles because the scope of what needs to be stored in the cloud per-user is reasonably limited. It is problematic for PCs because the remote identity service is free but the free tiers of OneDrive, iCloud, etc. are too limited to actually hold all of the user's data, and it's hard to clearly delineate what is or isn't synced when taking a mixed approach. Even smartphones have these problems, usually around text messages and full-resolution photos.

It's much better for users to stick with a solution that's simple enough for non-technical users to have a chance of forming an accurate mental model and and have correct expectations about the availability and safety of their data. But that approach doesn't make it as easy to bundle and upsell subscription services, so that's not the usage model commercial operating systems try to promote.

> It is problematic for PCs because the remote identity service is free but the free tiers of OneDrive, iCloud, etc. are too limited to actually hold all of the user's data

Not just that but bandwidth constraints as well. Especially upload bandwidth. I might have 1Gb/s down but I have only like 40Mb/s up.

Even if I could make the device file system sparse and pull what it needs on demand, that stuff still needs to get uploaded initially. And on many internet connections, depending on the user content, it could be a while before the whole thing makes it into the cloud.

No, I still prefer remote identity even ignoring "cloud" storage.

It is nice having my desktop session just be able to negotiate the permissions with my NAS seamlessly without needing to have a separate user account for the NAS. Same with accessing file shares on any of my devices.

On top of that it's also nice having that same identity work across all of my computers. When I change my password on one computer it is changed on all the computers I use. I never have to think "what was the password for this computer again?" The same account on my gaming PC is the same account on my personal laptop, my main home server, my wife's tablet when I use that, other gaming PC's at friend's houses, etc.

Personally, I really prefer using an IdP in my personal life, especially when its pretty stupid simple to set up and use. It can make a lot of things easier.

The kind of remote identity you're describing is what you can get with something relatively simple like LDAP. Unfortunately, that's not at all like what consumer operating systems are trying to support. Using a Microsoft account or iCloud account doesn't get you the easy NAS access, but does come with lots of other baggage.

"Relatively" simple. Save for getting access at different locations where there's no VPN connectivity between. I don't think it's usually recommended to have your LDAP endpoint public. And running an LDAP host is probably beyond most users, but basic home users can easily make a Microsoft or iCloud account.

And yes, using my Microsoft Account gets me pretty easy access to my NAS. I just grant permissions to MicrosoftAccount\me@hotmail.com and I get permissions. I just set it to MicrosoftAccount\my_wife@outlook.com and it works. I just grant it to MicrosoftAccount\my_friend@gmail.com (Microsoft accounts can be tied to any email) and it works.

I don't really experience much baggage though. Running an LDAP server to do it all comes with far more baggage and management woes for a home deployment. Trust me, I did it for many years before Windows 8+ was widespread. Domain trusts to log into friend's and family's computers with my account was pretty complex to manage and maintain along with actually bothering with site to site VPN connectivity. And when that one friend manages to wipe his forest root without backups...oof.

> And yes, using my Microsoft Account gets me pretty easy access to my NAS. I just grant permissions to MicrosoftAccount\me@hotmail.com and I get permissions. I just set it to MicrosoftAccount\my_wife@outlook.com and it works. I just grant it to MicrosoftAccount\my_friend@gmail.com (Microsoft accounts can be tied to any email) and it works.

What NAS, exactly? And how does it handle non-Windows clients?

What you're describing doesn't seem to be something that eg. run of the mill Samba offers, and it's something that Microsoft seems to be changing with every major version of Windows.

> Save for getting access at different locations where there's no VPN connectivity between.

Getting access to what?

> What NAS, exactly?

A small low power x86 Windows box. Used to be an older gaming PC, swapped for a lower power CPU with integrated graphics. Runs storage for an array, VMs, containers, video transcoding, etc.

Non-Windows clients can also log in with local accounts or with that same MicrosoftAccount realm login username/password. I've used some Pi's and other Linux boxes mounted that way in the past.

But it seems like it's decently well supported in Samba to auth like this though. I'm not sure what happens when their Microsoft account password changes though.

https://forums.unraid.net/topic/117723-allow-at-sign-in-smb-...

> Getting access to what?

Getting access to the LDAP server to handle auth. If I hop on my friend's spare computer at his house, how is it going to reach out to my LDAP server at home?

Same thing when I'm hopping on my dad's computer, or if he wants to use mine when he's visiting. This way we can just use our own logins and have access to our own files, resources, settings, etc. Regardless of whatever computer we're using. If I want him to copy his recent trip photos to the archive when.he comes over he can drag and drop them into the network share on the NAS with his own credentials on his own computer, as I've granted his Microsoft account access to write to the family photos. He doesn't need to remember his password to my NAS, his desktop login is his auth. Same when I'm at a friend's house and on his computer. I just want to pull some big file off my laptop over the network, I can just open up my shares on my laptop and grab whatever. I don't need a separate login to manage.

There's so much stuff that's just so smooth and seamless using an external, managed, widely shared IdP to handle identity management. Some negatives and risks, no doubt. But to me, it's a worthwhile trade off given how easy it makes these kinds of workflows I encounter daily.

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

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.

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.

For shared local usage or "pet" (as opposed to cattle) servers I'd agree, and in fact this is close to what Linux was designed for, since I'd consider the multiplexing lab server to also be a semi-trusted environment.

I'm referring more to how Linux is used in vast pools of "cattle" servers in Cloud, locally by eg one main user (who doesn't need multi-user but probably still needs some notion of "admin" and per-program permissions), or in a corporate setting (where the actual identity system is managed remotely). This is probably >99% of Linux environments.

Qubes takes that to an extreme: https://www.qubes-os.org/intro/ and runs every application in a virtual machine.

I was experimenting with taking that to a median using containers in nixos. IMO the distinguishing feature of qubes is the fact that there's chrome indicating the security level of a window based on its vm - I put together https://github.com/andrewbaxter/filterway to use with window manager rules to hopefully get the same result.

Interesting! I use Guix, I wonder if the fundamental idea can be translated here too. Do you have any links for the Nix-related stuff?

Arrg, I just realized I lost my demo system in a recent drive failure. So I don't have anything I can show directly... but this is my recollection.

I used systemd-nspawn containers https://nixos.wiki/wiki/NixOS_Containers .

For each container I'd run a `filterway` process with a unique app id outside the container and mount the filterway wayland socket inside the container, then wayland programs in the container would just work IIRC (maybe needed to set an environment variable for the wayland socket, or xdg_runtime_dir or something).

I think the wayland compositor itself was running as a user, so I had some setuid commands so that the system bar launch icons could start/stop the containers as the wayland user.

IIRC wayland was pretty flexible, just mounting sockets in various places and making sure permissions were set on the socket worked great.

Some other quick notes: App ids are optional in the wayland spec, but as long as you don't run any such apps in privileged contexts (outside of a container) you can still visually distinguish those. Also IIRC Sway didn't have the ability to vary chrome based on app id - I thought I'd try to indicate the permission level in the task/system bar instead but I think other compositors do have more powerful window decoration rules.

Impressive! I'm not sure Guix has something similar to nspawn containers

Hyprland has a way to put unique borders per appid too, I think.

That's already what's typical with services, e.g. postgresql.service specifies User=postgres.

  > Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized.

You’ll be interested to learn about systemd-nspawn. You can sandbox stuff with it really easily. It is like chroot so not really resource intensive, lighter than a container.

I think a pretty useful thing you can do is boot ephemeral instances. So whatever someone does there gets undone. Useful if you’re doing system testing or CI. Because you just set up the machine once and then your scripts and whatever can do what you want. Perfect example is when trying to test install scripts.

Though this is also kinda the point of flatpak and snap. Though these are controversial in the Linux community. Then again a lot it people dislike systemd, though fewer than originally.

https://wiki.archlinux.org/title/Systemd-nspawn

I read a good chunk of that wiki link, but didn't really come away with an understanding of how it differs from just using Docker for sandboxing an app.

Did you have any insight there you might share?

It's basically the same as docker but it doesn't use proprietary cloud stuff such as dockerhub.

Also occupies like 100kb instead of 40mb because it's C and not go.

It differs by not being insane. Trivial functionality that actually works. It's what's good about systemd.

It doesn't require forwarding sockets or giving free access to root just for building images. It doesn't explode just because you touch your nftables rules. It doesn't suddenly expose a process to the Internet because of some undocumented option. You can use all the normal tools such as auditd and SELinux without having your configuration overwritten by a madman.

How is it different from podman then?

It's not a docker replacement. Use podman to replace docker. Use system to start stuff (in a namespace or otherwise).

  > how it differs from just using Docker

It uses the system.

You’re missing the trees for the forest. At a high level they are the same, just as with LXC or podman or others. But it’s the details which are really important. Because your leveraging the system you can really shrink down the size, another user mentioned. But there’s also a convenience in just being able to use systemd when its already built into your system.

I suggest also reading

  man systemd-nspawn

Just type it into your terminal, you don’t need to install anything

The nspawn does look interesting, and potentially exactly what I want. Although, this wiki page is dense enough that I am concerned I am going to somehow misconfigure it and be less secure than I would be without using it.

I Flatpak wherever I can, but several of my required applications are not first-party packaged, which makes me extra squeamish about installing them.

For security read on systemd-exec https://www.freedesktop.org/software/systemd/man/latest/syst...

> As single user, each and every process has full and complete control of $HOME. I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized.

This is what OpenBSD's unveil does. Firefox for example only has access to ~/Downloads (and some stuff in ~/.mozilla, ~/.config, ~/.cache) in my home directory.

Now this looks promising for mere mortals. I found jart's Linux port of pledge[0] which makes it seem possible to simply wrap utilities through a preceding script. If I couple this with distrobox/podman (which should work fine?) I might be able to pretty seamlessly lock down utilities by default with minimal shenanigans.

Assuming it does what it says on the tin, and it can work with GUI apps, this would get me almost all the way.

[0] https://justine.lol/pledge/

You can get halfway there with Flatpak and Distrobox. Or you could take a look at some of the "immutable" distros, such as openSUSE Aeon [1].

[1] https://aeondesktop.github.io/

Those solutions seem more aimed at keeping the system clean vs isolating what resources a program can access.

Flatpak does indeed get me part of the way there with better isolation, but available apps seem so scatter shot that I need a fallback mechanism for when there is not an official Flatpak artifact. Distrobox makes a point of indicating they are not a security boundary.

If only firejail existed to do exactly that… it could come packaged in most distributions with sensible profiles that are easy to enable.

It might even have a github project that people might reach, something like this https://github.com/netblue30/firejail

Yeah that's possible but its still security as an afterthought, bolted onto an existing system.

And it's a bad UX also. As a user, I don't want to deal with fake users, for example.

*Nix was designed to be multi-user. It's probably the only security boundary that was present from nearly the start. I think there are some rough edges on the user-per-application model, but it should all be scriptable so that the machinations are mostly hidden.

Have you used containers?

I agree that multi-user should go away for modern server workloads, however, users are used as a blast door. Mainly because Linux's security model is lacking. systemd for example commonly runs services under separate users to make it more difficult for a compromised application to elevate privileges. Android does something similar AFAIK.

Users should have never became a security boundary to isolate applications, but they unfortunately have, and there's not really an alternative.

This is why I think multitenancy is the more important problem (though both are related), because it's the key to solving shared-kernel application permissions without "users". Containers were a step in the right direction but aren't a sufficient security boundary in themselves - what is currently handled by the "container runtime"/sandbox needs to be built into the kernel IMO.

> Linux's security model is lacking

It's not lacking at all. The root + users model is common not only across OSes but also all sort of physical devices.

Linux's security model doesn't become better just because everybody is doing it that way, and besides that, everybody is doing it because they are copying Linux.

> Linux's security model doesn't become better just because everybody is doing it that way

I didn't claim it does.

> everybody is doing it because they are copying Linux.

This is not true. The model existed decades before Linux.

Nah, its been lacking since inception, with people trying things like chroot jails and suid bits decades before Linux was a twinkle in an eye, and we still regularly fail at running untrusted code.

>systemd for example commonly runs services under separate users

Doesn't this have to be manually setup. Can i make systemd to run a service under a temporary user automatically.

Yes?

https://www.freedesktop.org/software/systemd/man/latest/syst...

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

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

> 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

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.

Can you tell me how many users of android, TV set-top boxes and other IoT device users are using sudo?

I hate to sound elitist, but I straight-up can’t do any serious coding on anything other than a Linux box. Most of what I do these days is statistical inference on bacterial genomes in the context of antibiotic treatment.

I understand that I’m not the average user, but then again, nobody really is.

That sounds like scientific coding, not serious coding

Serious coding like writing TODO apps for the latest WebTV?

Business applications are far more serious than any scientific code could ever hope to be

It’s because you are a Linux noob. Use a real Unix like macOS! /s

Let the flamewars begin!

If one is really hard pressed to use a windows box, I have found WSL to be a godsend. (eg at work, which is luckily at a relatively small company where IT isn't as locked down as other places I've worked.)

On the other hand, I tried to use powershell the other day for some simple admin tasks and ooooh wow I sure don't have anything nice to say.

Also my living is made on the Windows side, and not the Linux side, so I guess I don't know the pain points of WSL.

The ratio of linux desktop users:sysadmins I know is something like 50:1

Other way round for me

What kind of sysadmins are they then? I don't want to sound dismissive, but is a "windows sysadmins" a thing? Do companies run windows on servers?

windows sysadmins are very much a thing. desktop and laptop MS Windows installed in any company doing anything important is sysadmin'ed centrally. If you require security (not to leak company info) you must disable the ability for users to install anything. The side benefit of this is that the admins can admin other things like mail servers, ip addresses, etc. My gf (accountant) has to call the sysadmins to plug in an external display at home, which they can do remotely at 2 in the morning.

Companies absolutely run Windows servers. In fact, every single company I've ever worked for (except one very small company) has had them. Usually at a minimum, you will have servers running Active Directory, and perhaps DNS (because AD-integrated DNS zones are useful). Then, more often than not companies are MS Exchange shops, plus Sharepoint is common enough.

Generally people aren't running web servers on Windows, but the internal IT infrastructure world uses a ton of Windows servers.

> Generally people aren't running web servers on Windows, but the internal IT infrastructure world uses a ton of Windows servers.

With good reason I'd note, its a use case which windows is profoundly good at - whereas web servers are not something I would say windows is very good at.

> Do companies run windows on servers?

All of the Fortune 500 probably does.

I guess this is a matter of ‘bubbles’. Most people I know that have a Linux box at home - including my parents - are not and have never been sysadmins. But this is probably because there are not that many sysadmins in my bubble?

Kind regard, Roel (former physicist, developing Android apps (for fun) on my Linux laptop, owner of multiple NAS, but never having been a sysadmin in any company)

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

Sure. But sudo still serves a purpose for those folks.

I also use sudo on my macOS system(s) (e.g., MacPorts).

If you are in a team of sysadmins, you are still the local system administrator.

The only ones this message applies are the HPC ones and the "app folks", and the number of ssh-apps that require you to log in another computer is very small nowadays.

What is (theoretically, or practically) being achieved by running sudo instead of just logging in as root? Can you give an example that justifies typing your password up to hundreds of times per day coupled with deliberate hashing delays?

> What is (theoretically, or practically) being achieved by running sudo instead of just logging in as root?

Auditing.

> Can you give an example that justifies typing your password up to hundreds of times per day coupled with deliberate hashing delays?

1. I don't do that hundreds of times per day because the stuff I run generally runs pretty well.

2. sudo has password caching, so only the first execution needs a password.

3. If I'm doing a lot, I may sudo-to-root: auditing can still see me going in and becoming root, so it can be determined that I did stuff.

If a network intrusion detector warns about something being changed, you can review the logins to see that it happened right as an authorized person accessed the box. A common practice is to not allow root direct ssh access.

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

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.

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.

Not sure what the connection with Colorado U might be but I read this [0] a couple of days ago. Steve Bellovin had a few connections with formative Unix security and worked/studied with Fred Brooks and Ken Thompson, In the (linked) talk he says that Brooks taught him "about responsibility. Someone with the root password has not just the right but the responsibility to use it." This caught my attention because I'm writing a series "Technology: rights or responsibilities?" Maybe there's a thread of influence there?

[0] https://www.schneier.com/blog/archives/2024/11/steve-bellovi...

https://en.m.wikipedia.org/wiki/Evi_Nemeth was part of the early development of sudo. I did a double take years ago running "The Woz Lab" at CU Boulder, reading the sudoers man page and seeing the 128.138 address space in the examples that I was managing subnets of.

"This incident will be reported"

Surely they were thinking at the time that the user was a student.

the incidents were reported, email to root. Would you prefer that you get narc'ed silently?

I thought this is about the other warning, which has since been removed:

https://github.com/sudo-project/sudo/commit/6aa320c96a376136...

What's with all the F responses? I appearedly missed this fad.

https://knowyourmeme.com/memes/f-in-the-chat

Thanks

  # /etc/sudoers.d/99-insults
  ---------------------------
  Defaults insults

Thank me later. The number just defines load order (99 being last), you can use whatever you want.

You may also want

  Defaults env_keep += "EDITOR SYSTEMD_EDITOR"

I was at the University of Rochester as an undergrad working with the computing center's Unix Group when sudo added this message. We quickly modified our local version to read, "Friends don't let friends su drunk."

My first experience of Unix was on a dumb terminal on a university AIX (?) machine, I had heard that "man" was how you got to the documentation, so duly typed "man", the resulting

   Apropos what?

made me laugh out loud, and the others in the room gave me a funny look.

I've got no "sudo" command on my main Linux workstation: the only way to log in as root is by using a Yubikey, from another computer, which is on a private LAN only shared between my workstation and my "terminal" (an old laptop which I know only use as some kind of remote console/terminal to log in as root on my workstation). So on my workstation I allow ssh root login, but only using keys (no password) (and only on that private LAN). Getting in as root without the Yubikey means finding a remote exploit in sshd.

And in all my containers: no sudo command installed either.

As you may have guessed I'm not a big fan of sudo.

Is installing sudo in a container common? Don’t think I’ve ever seen that.

Any reason not to run SSH on localhost only? This way there would be no network requirement whatsoever.

I am not trying to criticize, but am just curious what you gain by having this access split across two machines?

A long time ago I also wasn't a fan of sudo so I used SSH only (password authentication from localhost). Eventually I stopped caring and stopped having strong opinions about sudo anymore.

sudo also had the ominous warning, "This incident will be reported!" when you fail to authorize the request. ofc, it just just logged.

I remember my first linux admin gig and mistyping my password when using sudo then getting an email about it a few seconds later. After years of home linux use this amused me and was like "oh, so that's what happens when things are configured properly".

It mails the root user by default.

FYI, you can turn this off by adding "Defaults lecture = never" to /etc/sudoers. In Nix:

    {
      security.sudo.extraConfig = ''
        Defaults lecture = never
      '';
    }

Or you could also set it to "always" to annoy your users :^)

It's about time we remove it.

Pretty wild that sudo is still the most common authorization framework for linux.

Sudo will temporarily get you in su, whereas the cu command calls another user within the original shell. Designating kernel privileges within an instantiation works in the absence of a w-r permissions setting scheme for designating cron tasks + programs.

s/cu /su /g

Reply on news.ycombinator.com