OpenBSD: Shutdown/reboot now require membership of group _shutdown | Hacker News Reader

OpenBSD: Shutdown/reboot now require membership of group _shutdown

undeadly.org

137 pointspeter_hansteen111 comments

The headline kinda makes it sound backwards. They did this to allow users to shutdown without also giving them a bunch of unrelated privileges.

New title:

OpenBSD: Unprivileged users can now shutdown/reboot via _shutdown group

Or this:

OpenBSD: membership of _shutdown group now sufficient for shutdown/reboot.

Requirement and sufficiency are very different things.

Yet its a free-for-all when it comes to power on?

Power ain't free

With physical access, sure. The same could be said for shutdown with physical access. Nothing stopping the user without group membership from holding down the power button or unplugging the kettle cable.

Grumbles something about standard computer power cables (IEC 60320 C13) not being ‘kettle leads’ (IEC 60320 C15) …

Though you can use actual high-temp rated kettle leads if you like - they fit and are safe in C14 sockets.

You mean your computer's PSU doesn't need a 120°C rated plug? Bro do you even CUDA?

When you "CUDA" the heat is the least of your problems. Did you ever see a single core copper cable become brittle like crackers?

In the UK and Ireland (and maybe elsewhere?), a kettle lead is actually C13. I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.

Most kettles now have a base with an integrated cable though, so the name doesn't really correspond with the cable's most common usage any more.

I had a friend who was easily teased by this, but he was quite right, and you are wrong. Kettle leads in the U.K. have never been C13, and "kettle lead" for a C13 power lead is a misnomer just as much in the U.K. as it is elsewhere.

When kettle power cords weren't captive, as they are nowadays, they weren't C13. Non-captive kettle cords from the middle 20th century were round pin, for starters, and not like the (later) IEC standard at all. Here's a round-pin electric kettle from the 1960s, for example:

https://www.modip.ac.uk/artefact/aibdc-02510

And "hot condition" or "high current" leads for other devices are not C13 now. Here's a high current power lead from Toolstation, for example:

https://www.toolstation.com/uk-plug-to-hot-iec-lead/p21431?u...

It's mis-labelled "C13" but it's clearly a C15 with a notch. Contrast with an actual C13 lead from Toolstation:

https://www.toolstation.com/uk-plug-to-iec-lead/p29256?utm_s...

Here's a hot condition power lead from BKA, for another example, which is again a C15:

https://www.bka.co.uk/iec-c15-hot-condition-power-leads

That first link doesn't support your point. No one would claim that all kettles ever sold in the UK have C13 cables. (No one would even claim that none use C15 – after all, some companies will surely just use the same design across all markets if possible.) This particular kettle is before C13 and C15 were even standardised.

The website it's from has a fair number of kettles from the relevant time period (1980s and early 90s). These two (which seem to be variants of the same model) [1,2] have an OKish view of the power connector and look more likely to fit C13 than C15 from what I can make out (no notch). This one [3] is clearly for C15 though, but as I say it's not a surprise that some exist.

[1] https://www.modip.ac.uk/artefact/aibdc-001258

[2] https://www.modip.ac.uk/artefact/aibdc-02488

[3] https://www.modip.ac.uk/artefact/aibdc-003345

On the contrary, it supports exactly the point made in the preceding paragraph, which even pointed out that the IEC standard came later.

The phrase "Should have gone to Specsavers!" comes to mind. All three of your examples clearly have notched connectors. Two have the notches at the top, and the Russell Hobbs one has the notch at the bottom. Their kettle leads were not C13.

So to repeat: When kettle power cords weren't captive, as they are nowadays, they weren't C13. I've already given an example of a kettle preceding the standard that didn't take anything like a C13 connector, and in vainly arguing against that you've ironically produced three more examples of kettles from later decades whose kettle leads were also not C13.

Here's yet another one, where the lead itself is in the picture. It's not C13.

* https://www.worthpoint.com/worthopedia/vintage-1970s-80s-had...

If there had been examples of kettle leads that were C13, I'd have long since used them to really tease my late friend. But kettle leads in the U.K. have never been C13, and my late friend was right that "kettle lead" for a C13 power lead is a misnomer in the U.K..

* https://www.specsavers.co.uk/book/location (-:

>I guess you need a beefier cable/pins in the US, as you're drawing more current at a lower voltage.

No, we just accept slow-as-piss kettles.[1] (Our plugs aren't great, either, it's pretty common for a spark to jump the gap of the leads while you're plugging it in.)

High wattage appliances here have an effective max of like 1.8kW on a single-phase 120V outlet, it makes for pretty useless space heaters and kettles. You could probably beat our kettles with an induction cooktop just by virtue of the stove being able to use two phases.

Truly it's a tragedy for those of us addicted to our hot beverages.

[1]: https://www.youtube.com/watch?v=_yMMTVVJI4c

>it's pretty common for a spark to jump the gap of the leads while you're plugging it in.

how are you plugging it in? Are you plugging the mains end into the wall before you plug the kettle end? That's truly bizarre to me, and goes against everything

> it's pretty common for a spark to jump the gap of the leads while you're plugging it in

Do you live underwater?

Indeed, our new cooktop in “power boost” mode boils water ridiculously fast. Our kettle is embarrassed.

> it's pretty common for a spark to jump the gap of the leads while you're plugging it in

If you’re referring to seeing a spark while plugging something in, that’s just current jumping from the socket to the pin that’s entering it - it’s nowhere near possible for current to jump between the pins on a single plug (in air, at least). The distance between pins was specifically designed to prevent that possibility at the given voltages.

Not saying our plugs aren’t poorly designed, just that that’s not one of their problems.

> In the UK and Ireland (and maybe elsewhere?)

I think its just the UK and Ireland where there's a demand for "high performance" kettles. The rest of the world is condemned to waiting longer boiling periods due lower-wattage kettles. I've had a British expat audibly exasperated by my kettle.

My Japanese kettle has a MagSafe cord.

Does it have Find My Kettle?

surprisingly that would have come in handy on more than one occasion.

As another post has commented, in Ireland we indeed use C13 cables, and it's pretty common to use this term for that here !

What about wake on lan?

Poor Ian.

or type ctrl-alt-delete to start a reboot, if that's not been disabled.

I think at one point that caused a console message: "This isn't DOS"

ctrl-alt-delete has not rebooted OpenBSD in a long time.

i am not surprised.

but the irony is that i'd prefer if someone trying to shut down my computer they would use ctrl-alt-del to initiate a clean shutdown/reboot instead of just pulling the power. in fact, if my GUI is stuck somehow, i'd want that for myself too.

"This isn't DOS" is rather inconveniencing myself for the sake of purity. i have been there too when i was young.

if it is followed with the right process for shutdown, I think that message is good. (like vim telling you how to exit, if you hit ctrl-c)

does BSD have sysreq commands like Linux?

What do you mean? Pressing the physical power button?

You've been downvoted, but you managed to make me smile.

Judging by all the downvotes and comments that there are quite a lot of people without sense of humor :-D

"Login required before powering on"

SCO OpenDesktop installation manual had something to this tune about booting and drivers :D

Isn't this essentially what full disk encryption demands?

Is the machine on or off at the point of the prompt?

Yes.

BeOS had this:

int32 is_computer_on(void)

    Returns 1 if the computer is on. If the computer isn't on, the value returned by this function is undefined.

should ping local electric company and check that the daily quota isn't filled

With physical access, if you can touch it, you can own it.

It was a joke (:

I was going to mention something about PXE, but according to Intel it has no security at all:

https://www.intel.com/content/www/us/en/developer/articles/t...

> As network technology has improved, the limitations of PXE Boot are more apparent. PXE has no mechanism for encryption or authentication, is susceptible to man-in-the-middle attacks, does not scale outside of local networks, and has reliability issues associated with TFTP time-outs and UDP packet loss.

[snip]

> One of the key issues with PXE is a lack of security. The TFTP & UDP transactions associated with PXE may be the last unencrypted traffic on your network and are trivial to intercept. This boot process goes against the “zero trust” concept applied to today’s networks.

However, UEFI to the rescue:

> The UEFI Specification introduced HTTP(S) Boot in in version 2.5. HTTP Boot combines the Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Hypertext Transfer Protocol (HTTP) to provide system deployment and configuration capabilities over the network. Compared to PXE Boot, HTTP Boot can handle much larger files than TFTP, and scale to much larger distances. PXE depends on UDP broadcast You can easily download multi-megabyte files, such as a Linux kernel and a root file system, from servers that are not on your local area network.

Because HTTP is now a layer of the network stack.

So I might not be able to turn on my computer because an X.509 certificate expired ;)

Yes, but more likely because of clock skew because the battery long ago died. Not that I've ever seen that...

But how is the network securely going to tell the computer which https server to use? I can get a certificate for any server I put on the network.

Using DHCP, the same tool that can configure any client computer with addresses and gateways, meaning you hopefully secure that already.

Some switches give you tools to mark a few physical ports as "truster", allowing DHCP OFFER from those; and drop (or ever shutdown the port!) when such a packet is received on an untrusted port.

If you can trust DHCP, why can't you trust TFTP? Your smart switch could drop TFTP packets just like it drops DHCP packets and you're good again.

(Yes, yes, pxe doesn't check for secureboot signatures)

So now nobody on your network can boot your computer, but everybody in the internet can.

Secure by design.

Where did you get the idea that anybody on the Internet can?

The first step to network booting (PXE or UEFI boot) requires DHCP, which means a DHCP server or relay on your local broadcast domain (switched LAN, and I'm sure there are extensions for boot-over-WIFI somewhere).

Sure your computer could fetch the boot image over the Internet, if you're okay with involving the unreliability of the Internet in your boot process, but that'd require explicit configuration on your DHCP server.

AMT/IPMI is more reliable than PXE and does support/require authentication

No, power on already requires membership of group _startup so no security problems there AFAIKS.

As well as _localpresence and _finger.

real users get power, few get _shutdown

Hahaha hillarious

I've always liked how the OpenBSD project just makes pragmatic changes and then documents them.

The various window manager/DE package maintainers will be modifying the pkg-readmes for 7.4 now I suppose.

/usr/local/share/doc/pkg-readmes

I always thought the one-group-per-privileged-action-or-device model could have been taken farther than it was rather than diving into ACLs and capabilities (which IIRC OpenBSD doesn't support anyways) or the various -kits. Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?

> or is there a deeper problem lurking there?

The problem is that organizations don't want to be told by computers to just use sane and logical structures for their meatbags, they'd rather spend billions on making the computers compatible with every single deranged edge organizational case that only exists because of 20 years of unmitigated office politics and/or warfare.

On the plus side, most of IT would be redundant if they ever smartened up, so let's hope they continue to wage their little wars through IT procurement.

Contrast that to how OpenBSD handled this. There was a thing, disk access, that shouldn't be allowed to those who could shutdown/reboot, so they bounced it around internally for a while, then de Raadt submitted a patch that said, "we're doing it this way, our users will figure it out, it's not a complex thing."

No massive re-architecting, just add a group, done. Businesses could learn a lot from the way the *BSDs and Linux do things. They're all different, but you can't argue with the results.

I actually think, given how the usage share of the BSDs is a fraction of that of Linux or Windows, that OpenBSD is a textbook example of how "good enough" almost always trumps technical excellence.

Linux is unquestionably less "cohesive" and "organized" than BSD but I can't think of any reason to reach for BSD given Linux exists.

They find sufficient usage; even if their utility hasn't become relevant for you, yet.

Actually I used to run OpenBSD on a Thinkpad as a daily driver. Did that for work at a startup around 2010, but it was a miserable experience.

For laptops, I've always found the least-miserable experience is to run what the manufacturer prefers as the OS. Sad, but true (for me).

Same! Though mainstream Linux distros are quite good these days, for ThinkPads and Dells

"Is it just that it's an absolute pain to administer, or is there a deeper problem lurking there?"

Deeper problem. Authorization in the general case can not be done with a set of simple textual tags. Consider sudo. A group might be able to flip on or off whether or not you have generalized sudo, but if I want Bob to be able to run these threes scripts, Betty to be able to run anything as root, and Billy to be able to run this exact script with this regular expression validating the argument, how are you going to do that with groups?

Obviously, you can use groups in the solution (each of those names can be replaced with a group identifying a set of people instead of an individual name), but you can't be creating an OS-level group for every tiny fiddly permission that may exist somewhere on the system, especially in contexts where the groups are shared across an organization.

Or, to put it another way, yes you could take any arbitrary policy and compile it down into a final set of tag-based permissions, but nobody would want to deal with the resulting thousands/millions of little group tags. It is technically possible but not a win on any level. For example, would you prefer an ACL that says you can access some resource during business hours, or an appearing and disappearing group tag?

ACLs and capabilities may suck in some ways, but a quite significant amount of the suckage is fundamental to the problem space. As humans we just don't want to be that specific about security.

> nobody would want to deal with the resulting thousands/millions of little group tags

But... you have to? You can hide it behind polkit or ACLs or capabilities or whatever but you still have to actually specify the logic.

It's something I'm still annoyed about as we port a realtime application to rtkit: it's the exact same limits you used to have to establish in /etc/limits.conf but now they're in a different place. That doesn't actually simplify anything; you still have to establish the same limits.

What's with the leading underscore? That seems rather unprecedented. Is there some standard that BSD is setting for this?

It's probably to avoid conflicting with potentially existing user-defined groups. The underscore in the C/UNIX world has an intrinsic meaning of "implementation reserved", so it's your fault if the new group conflicts with one you improperly created yourself.

Some other software can think the exact same thing.

This is why I only name users, groups, directories, etc, with UUIDs

"Some other software" that uses/adds users and groups on the system, is not part of the implementation of users and groups in the system.

All of the system group names that own resources for specific applications have been underscore prefixed for years... like

  ...
  _bgpd:*:75:
  _tcpdump:*:76:
  _dhcp:*:77:
  _mopd:*:78:
  _tftpd:*:79:
  _rbootd:*:80:
  _ppp:*:82:
  _ntp:*:83:
  _ftp:*:84:
  _ospfd:*:85:
  _hostapd:*:86:
  ...

but not the general ones like wheel, sys, daemon, tty, nobody, etc.

Prefix code blocks by two spaces.

Now I wonder why my FreeBSD systems use underscores for some groups, but only a few of them.

  $ grep ^_ /etc/group
  _pflogd:*:64:
  _dhcp:*:65:
  _ypldap:*:160:

Yeah thanks, I edited that like 10 times dealing with escaping the asterisks with backslash, adding the two spaces, removing the escaping, newlines, etc :)

All of those are examples of privilege seperated software imported from OpenBSD, pf and thus pflogd(8), dhclient(8) and yplapd(8).

https://www.openbsd.org/innovations.html

If I recall correctly, all system groups should have a leading underscore for OpenBSD. However, they make exceptions for groups that have been around long before this became their standard.

It's to set system applications' resources aside, and it's more of an OpenBSD thing than a *BSD thing. Once in a blue moon you'll see it in the Linux and general *nix world as well:

  _chrony:x:112:  <-  Debian

It's a majority of the BSDs. NetBSD:

  _pflogd:*:18:
  _rwhod:*:19:
  _proxy:*:21:
  _timedc:*:22:
  _sdpd:*:23:
  _httpd:*:24:
  _mdnsd:*:25:
  _tests:*:26:
  _tcpdump:*:27:
  _tss:*:28:
  _gpio:*:29:
  _rtadvd:*:30:
  _unbound:*:32:
  _nsd:*:33:
  _dhcpcd:*:35:

Debian, in their Policy 4.5.0 said:

"When maintainers choose a new hardcoded or dynamically generated username for packages to use, they should start this username with an underscore."

https://www.debian.org/doc/debian-policy/upgrading-checklist...

I wonder if the endgame is that each suid binariy will have separate group associated with them. I don't have obsd at hand, what the situation is like currently?

I believe the current tally of suid executables having their own separate group is: crontab, ssh-agent, authpf, and smtpctl (smtp-queue).

I thought this was something similar to Microsoft mandating membership to update OS

Oh wait, I always shut down by running `doas halt`, is that incorrect? >_>

OpenBSD is unique amongst the BSDs in that its halt(8) and reboot(8) commands use the rc(8) system to shut down services gracefully, so the only thing you're missing is scheduling and shutdown message broadcasts.

Elsewhere those commands simply broadcast SIGTERM/SIGKILL to all processes, so you should use shutdown(8) unless you're in single user mode.

poweroff(8) has halt/reboot semantics on NetBSD, but shutdown semantics on FreeBSD/etc.

For those unaware, Undeadly.org is a very unusually engineered site. It's written in C, and it runs under FastCGI on OpenBSD's (edit: home-grown) httpd.

> it runs under FastCGI on OpenBSD's fork of httpd.

FWIW, OpenBSD hasn't used [a fork of] Apache in nearly 10 years. Since OpenBSD 5.6 /usr/sbin/httpd has been a homegrown HTTP server, originally based in part on relayd, an HTTP proxy and another bespoke OpenBSD project. OpenBSD httpd can only serve static files or forward requests to a FastCGI handler.

Another success story for the BCHS stack.

https://learnbchs.org

>The xfce port has already been modified to accommodate this.

Where are the diffs?

The links also don't contain it. Mailing list based workflows....

Oh, the irony of linking to GitHub.

https://github.com/openbsd/ports/commit/bf33ea5f3ff390d8cde3...

https://github.com/openbsd/ports/commit/469b0a4b0a1152576d93...

> https://github.com/openbsd/ports/commit/bf33ea5f3ff390d8cde3...

Now, this is surprising. I randomly clicked on that link and I immediately see that the code and the patch has a bug. It only checks the first 8 characters:

    -      if (gr != NULL && strncmp(gr->gr_name, "operator", 8) == 0)
    +      if (gr != NULL && strncmp(gr->gr_name, "_shutdown", 8) == 0)

so it will also match a group named "_shutdow" or "_shutdow1234" because only the first 8 characters matter.

A trivial silly mistake like this is... not what I expected considering OpenBSD's reputation for security.

It's a long-shot but I wonder if OpenBSD has specified that groups are only unique up to 8 characters.

Like it certainly looks like a bug to my eyes too, but my default when I see something like this in OpenBSD code is "maybe I just don't get it".

If OpenBSD had specified that groups are only unique up to 8 characters, wouldn't they avoid to specify a "_shutdown" group of higher length?

Looks like an overlook to me. Double click on operator, yank, type the new group name, done. Or even a quick replace all not noticing there was an hardcoded length right after one of the occurrences. The parent might have found an actual issue.

But happy to join you in the "maybe I just don't get it" clan.

You still need to be root to create groups and assign them to users, so probably not a big one and it will probably work all the time in practice.

How funny is this, someone randomly asks for the diff on HN for no apparent reason, someone else gives a link, someone else randomly opens the link and finds a potential bug.

Eyeballs, shallow bugs…

Looking back at the change after lunch it does seem like it was a rename without realising the strings were a different length. Actually changing "operator" to "shutdown", confirming the length was the same and didn't need to change, then realising it needs to be prefixed with "_" but not updating the length param would explain this nicely.

Yep! I like this theory.

Related: how many times I introduced bugs after some quick refactor on some careful code to make a linter happy.

Yes, yes, tests, I know.

Oh yeah, don't worry we have all been there :)

If that's the case, there should be a #define for that length.

If not, they should be using strlen("_shutdown") or sizeof("_shutdown")+1

There's really no excuse for a magic number there.

you'd want strlen("_shutdown")+1, since checking without the null-terminator means that you match with strings like '_shutdown123'.

It's one of the reasons why I detest the strcmp warning, as strcmp is perfectly safe given a literal string as a comparison, the comparison will drop out as not matching whenever the first NUL happens, and a literal string acts the same as specifying 'n'. Blind usage of strncmp leads to perhaps even more bugs than blind usage of strcmp.

That would introduce a bug. See the following:

    #include <stdio.h>
    int main()
    {
        printf("%lu\n", strlen("_shutdown"));
        printf("%lu\n", sizeof("_shutdown"));
        return 0;
    }

This prints the numbers 9 and 10 (on gcc I have). So if you used `sizeof(...)+1` when calculating the length argument for strcmp you'd be comparing the 9-byte string, the null terminator and one character of random nonsense.

facepalm, should have been strlen+1, not sizeof+1

Yeah naming things and off-by-one errors - the three most common bugs in CS ;)

Wouldn't that mean that `operator` would match `operator1234` since it doesn't compare the NUL?

> "A trivial silly mistake like this is... not what I expected considering OpenBSD's reputation for security."

Forgetting that "_shutdown" is 9 characters is definitely an oversight on their behalf. But you need superuser privileges to create groups, and at that point you can also just toss any user right into the regular _shutdow(n) group.

There's not really anything to exploit here, but if this type of comparison is present in other software - whether OpenBSD's system tools or not - I can definitely see how it has a general potential to cause a sysop to accidentally "cross-pollinate" his or her users, e.g. "ftpuser<some digits>".

>A trivial silly mistake like this is... not what I expected considering OpenBSD's reputation for security.

It may be a comfort to know that XFCE is not part of OpenBSD, then.

But that change isn't in upstream XFCE.

It's in the OpenBSD ports CVS tree, as can be seen by the fact that it's adding the file `x11/xfce4/xfce4-session/patches/patch-xfce4-session_xfsm-shutdown-fallback_c` and `/patches/` means it's part of the OpenBSD-specific `ports` infrastructure.[0]

The change might be submitted and accepted upstream in the future, but I think it's hard to justify this particular change as not being part of OpenBSD at the moment.

[0] https://www.openbsd.org/faq/ports/guide.html#PortsChecklist

Is this not just a cosmetic thing? Xfce wants to know if you have shutdown permissions so it can render the right buttons for what you can do, but so long as the code isn't running privileged it's not actually going to let you do anything — it'll just run /sbin/shutdown fruitlessly.

It also previously matched operator9000, so the intent was obviously a simple prefix check, and thus preserving that behavior is essential to avoid breaking userland.

How is that obvious? Isn't it more likely that the author forgot to account for the terminating zero?

Yeah, strncmp is the wrong function, but it was already wrong before the recent change.

Reply on news.ycombinator.com