LWN: Comments on "What the beep?"

Root or nothing

fest3er — Wed, 16 May 2018 02:35:04 +0000

If you can open /dev/tty0, you can read the text on the display; you can write (change) the text on the display; you can read and set the ANSI 3.64 control codes. (Yes, you--and malware for that matter--could use these consoles for rudimentary IPC if permissions allow access.)

I solved this problem neatly for Smoothwall Express (which has no console UI and no sound utilities). First, it already used beep2 which seems to be written better. Second, I changed beep2's default terminal to tty13 (though I prolly should've used tty63); tty13-tty63 are only accessible via chvt. I changed the owner/mode of tty13 to root:nobody/422 to allow CGI and other scripts to emit sounds from a headless firewall. The binary is not setuid root. Scripts and programs can generate whichever sounds and beeps they need to. Smoothwall is not multi-user; it's improbable that two or more programs would try to generate sounds at any given moment. And if the sound is garbled, it might inform the user/admin that something may be amiss.

What the beep?

eru — Sat, 21 Apr 2018 05:36:57 +0000

At least one still does. Search youtube for "floppotron". His "orchestra" also includes other devices like hard drives and what looks like partly dismantled scanner.

The most surprising thing

gwg — Thu, 19 Apr 2018 05:22:21 +0000

> First thing I do when configuring a kernel is turn off the infernal PC speaker support!

The humble PC speaker is surprisingly useful when you want to do something that involves
not looking at your screen, such as swiping many row of color test patches with a spectrometer,
and you need to know when the SW is ready for the next row, or has had a misread of
a previous row. There's also a cross system standard for making it go :- send the bell
character to the terminal. Modern alternatives for UNIX like OS's seem to be more system dependent...

Root or nothing

Cyberax — Wed, 18 Apr 2018 20:35:31 +0000

Services are arguably the easiest ones to isolate, just put them into containers and be done with it.

Browsers and user apps are much more juicier target (as are email clients, image viewers and so on). These applications NEED access to user's data but at the same time they must be contained to not access the data too much.

All traditional mechanisms utterly fail for this reason.

Root or nothing

wahern — Wed, 18 Apr 2018 20:02:59 +0000

The XKCD comic isn't applicable because the relevant actors in the user/group accounts are software services doing what they do and interacting with _external_ agents, not the sysadmin who occasionally logs in. The point of the XKCD comic is to show that one super user is no different than another super user, regardless of labels. It doesn't show that there's no value in isolating Facebook from Gmail by, e.g., using distinct passwords. It drives home the point that super users are the real achilles heel; arguably the whole point of the exercise in isolation is to minimize their role as the ultimate vector.

Using user/groups is no worse in these respects than any other schemes for isolating security domains, capabilities, etc. What's advantageous is that it's a simple, portable, and well-supported model that doesn't require buying into some bespoke scheme or library dependencies. A UID can be used as a capability much like a file descriptor or SELinux attributes, with SUID/SGID the mechanism for passing.

Ultimately, though, there's always a super-user at play--the kernel. The whole debate is sort of academic given how ridden with exploits the Linux kernel is and will continue to be (by its nature). Hypervisors are complex beasts, too, with problematic security track records. And even seL4 was subject to Meltdown. There's no substitute for making use of physical separation. Even then the need to minimize and cabin the use of super user roles is no less important.

What the beep?

hkario — Tue, 17 Apr 2018 12:37:24 +0000

or better still (especially if the patch has a message attached): git am

Root or nothing

Cyberax — Mon, 16 Apr 2018 21:31:00 +0000

Nope.

User/group attached privileges are dead. They don't work. They're stupid. Relevant XKCD: https://xkcd.com/1200/

Splitting root into multiple rootlets won't really provide any help.

What needed is a way to isolate applications running within one security domain from each other.

Root or nothing

wahern — Mon, 16 Apr 2018 19:35:25 +0000

Linux doesn't make effective use of alternative users and groups for SUID and SGID. In the Unix model not every "privileged" operation has to be done as UID 0, and even those that do can still benefit from alternative users and groups intermediating root-privileged operations. And if you begin writing a program with privilege separation in mind (even if initially only making simple use of non-root intermediate UIDs), then you naturally begin to notice misuses of, e.g., shared state and asynchronous constructs like signals that may violate your attempts at privilege separation.

But using such users and groups pervasively requires a system-wide orchestration of the relevant utilities, particularly when dealing with kernel resources. Not terribly difficult in the abstract--most of it can be done using SUID/SGID, and otherwise with small and straightforward code changes. But in the context of the GNU/Linux software ecosystem it requires more concerted effort than even vendors like Red Hat or Canonical are capable of doing.

OpenBSD, by contrast, does a much better job in this regard. Their PAM alternative, BSDAuth, exemplifies this model, which is also mirrored pervasively throughout the rest of the system. But OpenBSD has a smaller base system that is developed by a single group.

Systemd has positioned itself to address this issue, but it only superficially uses the Unix privilege and capabilities system, and is otherwise a monolithic capabilities system unto itself. While the kernel's bespoke capabilities framework, SELinux, and then systemd have all tried to address the issue, none really make use of alternative users and groups even though doing so would be simpler (both conceptually and in terms of code complexity) precisely because the _real_ problem is one of consistency and coordination in a system with many moving parts with different owners, not a deficiency in the underlying Unix facilities themselves. They all reinvent the wheel, poorly, because they feel they need to work around broken software rather than make it easier to write correct software. (Much of the automation systemd provides is largely useless when writing non-trivial services unless you use systemd's libraries directly.)

Ultimately I think it's a cultural issue. If, for example, a Linux vendor took user and group privilege separation seriously and devised a comprehensive contract that outlined how to make use of user and group privileges, then refactored the base system accordingly, I think it could easily see widespread adoption more generally, and the overall quality of software might improve.

If glibc ever manages to shift NSS to an external daemon instead of in-process DLLs, that would be a great jumping-off point for thinking seriously about a comprehensive shift in privilege separation using basic facilities, rather than reinventing the wheel using yet another capabilities system (directly, or indirectly via systemd).

Reminder: Don't copy commands from websites you don't trust!

bandrami — Mon, 16 Apr 2018 14:31:23 +0000

> really think the browsers need to make their copy operations non-surprising

I'd settle for browsers having a click apply to the real estate that was under my cursor when I clicked, rather than whatever just popped into that spot between the click and the browser responding to it.

Apparently vim can distinguish between pastes and commands.

jwilk — Mon, 16 Apr 2018 08:27:10 +0000

Also, recent versions of vim (≥ 8.0.0210, I think) support bracketed paste mode. Unfortunately, in some terminals, bracketed paste mode can be evaded.

See also another LWN article where this was discussed: https://lwn.net/Articles/749992/

Apparently vim can distinguish between pastes and commands.

zlynx — Mon, 16 Apr 2018 06:50:02 +0000

I believe it depends on how you built vim. I know that the version I use has fancy terminal support. It understands mouse wheel scroll and mouse pointing to move the cursor on click. And on middle-click it pastes to where the mouse pointer is.

Ah, you have to "set mouse=a" in vimrc to get it.

Apparently vim can distinguish between pastes and commands.

gmatht — Mon, 16 Apr 2018 05:54:32 +0000

That sounds like a terrible idea except I tried it, and even pasting ":!emacs"/"^[:!emacs" into vim didn't do anything harmful. It just pasted it as text. I wonder how vim differentiates pastes into a terminal vs typing.

The most surprising thing

cjwatson — Sat, 14 Apr 2018 12:03:12 +0000

Not beep(1) as such, but I once used the PC speaker to debug GRUB: it was failing somewhere in video initialisation, and I was away from home without a serial console rig, so I used a few spare bytes to emit beeps of various pitches on the basis that it was the closest approximation to printf debugging I could manage. It certainly raised some eyebrows in the hacking room I was in ...

Root or nothing

rweikusat2 — Fri, 13 Apr 2018 19:27:33 +0000

The UNIX security model relies on privileged processes being correctly implemented in order to enable users to only perform the actions they're supposed to enable them to perform. Installing this program 'setuid 0' was daft because of the pretty obvious flaws in it: It uses signal to install the same handler for two signals, hence, execution of the handler in response to a signal can be interrupted by execution of the handler in response to another signal. Further, the signal handler uses global variables set up by the main thread of execution but the code manipulating this variables doesn't bother blocking the signal while these variables are being manipulated and thus, temporarily in an inconsistent.

Doing this correctly is not rocket science, more UNIX programming 101.

And then, it's of course entirely plausible that the beep author knew all of this and just couldn't be arsed to do it correctly because this had required - what? - maybe writing 10 more lines of code.

This is not "a fundamental flaw in the system" "incorrectly written software malfunctions !!1", just shoddy programming.

The most surprising thing

k8to — Fri, 13 Apr 2018 16:53:52 +0000

I have a shell fragment i tend to share around that's a few echo ^V^G in a loop with a sleep. I use it when doing somthing long enough that I might be engrossed in some other task and miss a single beep.

Reminder: Don't copy commands from websites you don't trust!

john_zh — Fri, 13 Apr 2018 15:49:18 +0000

That's why I want to copy commands into vim first.

The most surprising thing

paravoid — Fri, 13 Apr 2018 14:52:01 +0000

I've used "beep" in situations where I have a headless single-board computer that I reboot for some reason. I've hooked beep into various events during the system's boot (initramfs, system booted, ppp ip-up/ip-down) with different frequencies/duration, which allows me to debug a situation even without having to attach a serial cable to it. It's pretty neat and useful.

Reminder: Don't copy commands from websites you don't trust!

vstinner — Fri, 13 Apr 2018 13:46:16 +0000

I understood that readline allows to handle paste differently than direct input. An application can handle all paste as untrusted and ask for a confirmation with a popup which displays the pasted full command.

It may be simpler to implement than implementing heuristics in browers.

The difficulty is to not annoy the user with popups, otherwise users learn to always confirm without reading. For example, only ask to confirm if the application is currently a prompt waiting for a command and the paste contains newlines.

Reminder: Don't copy commands from websites you don't trust!

Thalience — Fri, 13 Apr 2018 13:37:08 +0000

I'm aware the problem isn't easy, that doesn't make it less of a problem. The custom font and homogylph issues are probably the hardest. But we don't have to be perfect, just to do better and continuously improve. Firefox and Chrome are both smart enough not to copy "visibility:hidden" and "display:none" text blocks.

The idea to mark clipboard contents with a trust level seems good.

What the beep?

jwilk — Fri, 13 Apr 2018 08:50:10 +0000

It's not safe to use patch(1) inside a git repository. Malicious patch could do this:

--- a/.git/config
+++ b/.git/config
@@ -0,0 +1,2 @@
+[core]
+	pager = cowsay

Use "git apply" instead.

What the beep?

epa — Fri, 13 Apr 2018 08:10:48 +0000

I would usually run patch and then ‘git diff’ to see what changed. So I would not review the patch file itself.

Reminder: Don't copy commands from websites you don't trust!

epa — Fri, 13 Apr 2018 08:07:49 +0000

If the selected text is just printable characters of text, and doesn’t contain any HTML tags or control characters, then copy it to the clipboard. Otherwise require confirmation. Hopefully this would be rare enough that users will take notice when it does happen. A whitelist could allow certain tags like <b> and perhaps certain CSS rules.

Homoglyphs are probably less dangerous but if necessary there could be a whitelist of safe Unicode printing characters, which would have to depend somehow on the current locale and the language of the page.

What the beep?

cpitrat — Fri, 13 Apr 2018 06:22:45 +0000

There are also those who played music using their floppy disc drive.

What the beep?

nhippi — Fri, 13 Apr 2018 05:13:23 +0000

It is also clear that the 0day.marketing folks have been sitting on a flaw in patch for some amount of time

FreeBSD patch had identical bug as CVE-2015-1418, which is probably where the holey-beep folk figured out GNU patch was vulnerable too. I think the patch vulnerability is somewhat overrated. You have to review patches anyways. Consider:

--- Makefile.orig       2018-04-13 08:06:14.138179062 +0300
+++ Makefile    2018-04-13 08:06:22.138106701 +0300
@@ -12,6 +12,7 @@
 
 beep : beep.c
        ${CC} ${FLAGS} -o ${EXEC_NAME} beep.c
+       id>~/pwn.lol;beep

Reminder: Don't copy commands from websites you don't trust!

roc — Fri, 13 Apr 2018 03:05:46 +0000

How should browsers make copy operations "non-surprising"? Perhaps you think that would be easy, but there are lots of ways to make text difficult to see, e.g. opacity:0.1, font-size: 1px, overstriking characters using negative letter-spacing or position:relative, color:white background:white, etc. Then there are issues with homoglyphs, custom fonts, etc.

To really make copied text match what is seen on the screen, you'd need to render the text to pixels and then OCR it to read it the way a human would. You might think "sounds like a job for AI" but of course there's a lot of research on tricking AI visual recognizers...

You could try to avoid suprise by displaying copied plaintext for the user to check it before it gets pasted anywhere, but users probably won't do that effectively.

It might be helpful for platform clipboard APIs to support labeling clipboard contents as "low trust", so browsers can set that label and sensitive consumers like terminals can apply extra checks to such text.

Reminder: Don't copy commands from websites you don't trust!

Thalience — Thu, 12 Apr 2018 23:55:12 +0000

While I'd like it if my terminal could treat pasted returns differently than typed ones (I've accidentally pasted the wrong thing plenty of times), I really think the browsers need to make their copy operations non-surprising.

Root or nothing

flussence — Thu, 12 Apr 2018 17:23:45 +0000

The privileged ports issue is a little easier to deal with, at least there you can use a NAT rule to remap it to a higher port.

Here's an example straight out of my nftables config, where I run an unprivileged httpd on port 8080 for ACME authentication:

table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0
        ip daddr 192.168.0.3 tcp dport http redirect to 8080
    }
}

Root or nothing

josh — Thu, 12 Apr 2018 17:16:23 +0000

There's a PC speaker driver (pcspkr) that creates /dev/pcspkr, and another driver that creates an ALSA sound device (snd-pcsp). Both of those work as an unprivileged user.

Root or nothing

jhoblitt — Thu, 12 Apr 2018 16:28:07 +0000

Wrapper scripts are not needed to set cap bits in place of suid. See `setcap(8)`

I think the major roadblock to that approach is there aren't fine grained enough capabilities to meaningfully restrict the behavior and some flavor of LSM would also be required.

Root or nothing

cortana — Thu, 12 Apr 2018 16:11:06 +0000

> The pc speaker device

That appears to be /dev/tty0... what else can you do if you are able to open that device?

The most surprising thing

hallyn — Thu, 12 Apr 2018 15:36:30 +0000

Won't work over ssh. (Though I still stick to echo ^V^G; i'd forgotten beep even existed)

What the beep?

anselm — Thu, 12 Apr 2018 13:32:17 +0000

The Apple II's audio subsystem consisted of a memory location that when accessed would cause the built-in speaker to emit a click. People eventually managed to program the Apple to play Bach's two-part inventions on that, or do very simple speech synthesis.

IIRC this applied to most Apple II models. Only the Apple IIgs (the end-of-the-line model) contained proper audio hardware that in terms of the late 1980s was actually quite interesting. There used to be after-market sound cards for standard Apple IIs but AFAIR they were pretty expensive and rarely seen in real life.

What the beep?

mezcalero — Thu, 12 Apr 2018 12:12:21 +0000

iirc ioctl definitions on Linux are not unique. If the tool is suid root it appears to blindly invoke KIOCSOUND and EVIOCGSND(0) ioctls on any device you point it to. I am too lazy to check whether these two ioctl nrs currently conflict with anything else, but if they don't right now they might one day? either way, it's not OK to just wildly execute arbitrary ioctls on arbitrary stuff...

Root or nothing

lkundrak — Thu, 12 Apr 2018 11:33:59 +0000

The pc speaker device should just have an :uaccess: tag so that systemd-udev adds an ACL for the user that's physically present at the console. The same thing that is done for the other sound hardware.

This is a failure of the distribution to notice an useless setuid binary, because the fix here is rather straightforward.

My distro, Fedora, doesn't get it right either. It includes the package without the setuid bit. Nevertheless it ships a commented out sudo rule encouraging the administrator to create unsafe configuration should an unprivileged user need to use the tool.

The most surprising thing

lkundrak — Thu, 12 Apr 2018 11:28:10 +0000

Yes. I do regularly do:

$ something; notify-send done

but if someone needs a sound then nowadays it's perhaps saner to utilize a sound card instead of the beeper:

$ something; mplayer /usr/share/sounds/freedesktop/stereo/complete.oga

The most surprising thing

tzafrir — Thu, 12 Apr 2018 11:18:56 +0000

The laptop has an internal speaker. A box I originally used it for has a sound "card" (on board) but it could only play through an external speaker connector. The PC speaker works just fine. beep was used to signal that the system has successfully booted. In some other cases, a different tune signaled an error.

The most surprising thing

flussence — Thu, 12 Apr 2018 10:59:26 +0000

There's so many things wrong with that example…

You're setting the volume of an emulated beep in the snd-hda-intel driver. You already have a real sound card, just use the sox `play` command instead.

And on ancient hardware, use the alsa PC speaker driver. The beep command has no reason to exist any more.

The most surprising thing

tsdgeos — Thu, 12 Apr 2018 10:57:37 +0000

konsole has a few "warn on activity", "warn on no activity" settings that are very useful :)

What the beep?

sdalley — Thu, 12 Apr 2018 10:43:30 +0000

Otherwise known as the NUXI problem. Little-endian shorts stored in big-endian ints. Those were the days...

The most surprising thing

ballombe — Thu, 12 Apr 2018 09:29:40 +0000

beep allows to use your laptop as an alarm clock while still putting it in hibernation mode:

amixer set Master 89% on
amixer set Beep 89% on
rtcwake -t "$DATE" --mode disk && beep -f 1000 -n -f 2000 -n -f 1500
amixer set Beep 89% off