On Fri, Dec 16, 2016 at 11:51 AM, Miroslav Rovis <miro.ro...@croatiafidelis.hr> wrote: > On 161216-08:35-0500, Rich Freeman wrote: >> >> I'm not sure I understand what distinction you're making. I can't say >> I'm intimately familiar with the security model around Pulseaudio (at >> a glance it seems similar to X11 with its use of cookies, though >> obviously if you tell it to broadcast unencrypted multicast RTP on >> your LAN you'll get the obvious effects) but X11 has a couple of >> glaring security weaknesses. The most obvious is the fact that any >> random X11 client can read the keyboard input of any other client on >> the same server unless you jump through a bunch of hoops that I don't >> think anybody actually jumps through (though I do believe some of the >> X11 PIN entry programs may use them at least). Anything you type into >> an xterm could be read by your browser, and in turn by any code able >> to execute outside any sandbox that browser might have (root privs not >> needed for this). > > I don't claim it can not, but I doubt anyone can do it in my > grsecurity-hardened based Gentoo machine.
As far as I'm aware grsecurity provides no protection against X11 client evesdropping. This is an X11 "feature" and not an exploit per-se. Here is one overview of the possibilities: https://pipefish.me/2012/08/28/spying-on-screens-and-keystrokes-the-dangers-of-open-x11/ Any program that has access to your X11 cookie and which can connect to your X server (which includes anything actually displaying a window on your screen), can generally grab any of the keyboard input bound for any window on your screen. There are ways for programs to block this, but they're not super-practical. Amusingly enough I stumbled upon this blog: https://blog.separateconcerns.com/2014-10-24-cli-passwords.html This page "helpfully" suggests that you can secure your system by using a console pinentry program instead of an X11-based one, with the underlying assumption being that console software is more secure for this sort of thing. While the basic assumption is probably true, in this particular case it is definitely not. Entering a password on an actual virtual console or over ssh is in fact secure. However, entering it into an xterm (which is presumably what you're using if you would otherwise be using an x11 pinentry program) is absolutely not secure. The x11 pinentry program probably uses XGrabKeyboard to ensure that other clients can't evesdrop, while the console-based version doesn't know anything about x11. Some xterm implementations have a secure mode buried in the menus which turns on this mode which you can use to safely enter passwords, but almost nobody knows about this. There are a lot of "cargo cult" tips out there which are based on a lack of understanding of how software like X11 actually work. Of course, X11 is so convoluted that almost nobody actually understands everything about how it works, which is why Wayland has always been right around the corner. In general, though, it largely dates back to an era where people had rsh listening on all their hosts. > >> And I wouldn't be surprised if a lot of X servers still run as root >> for modesetting/etc. > > What user is that? It you want, tell me how to check it, and let's see > how spyware-prone my system is. If you don't have USE=-suid on your xorg-server package, then X is probably running suid root. In order to not have it run this way you need support for kernel modesetting. I was surprised when I found out that X11 even worked that way (we're talking late 90s here). It seems a bit like running pppd as root so that it can directly talk to a UART because you have an aversion to using /dev/ttyS*. In any case the kernel devs have generally been making the move to kernel modesetting so that your device drivers actually are in the kernel and not in random userspace programs (I'm all for microkernels, but not like this). If you don't have kernel modesetting enabled then X11 won't be able to run with -suid set. Google for gentoo kernel modesetting for a guide on how to enable it on most modern hardware. > > It's been discussed over and over again. Lots of people are firm in > their understanding that Lennart is an actor by and for the big > business. Me too. Well, he is a Red Hat employee. Nobody really debates that. > > Whatever would anybody try to claim Pulseaudio code is, but to make up > for what was missing in some FOSS GNU Linux boxen for the missing > functionality that the big players couldn't otherwise get for their > Total Surveillance... > Uh, if the NSA wanted to spy on your box I doubt they'd do it by trying to sneak something into the open-source pulseaudio code that has numerous maintainers and which is copied all over the place. They'd probably just load some microcode into your audio hardware, and have it talk to some microcode in your NIC hardware, and if they needed some buffer they'd work it into your hard drive firmware. Then it works no matter what OS you're using at the moment, or even if you boot off of a DVD. And if they did want to do it more traditionally in userspace, they'd hardly be foiled because you aren't running Pulseaudio. They'd just modify your ALSA drivers or run a program that simply opens your microphone and sends the audio to some remote host. In the end whether software works for you or against you largely depends on how well you understand how it all works. Don't get me wrong, there are lots of good reasons not to use Pulseaudio. I probably wouldn't run it on a server, unless it was something like a home music server. However, on a traditional desktop it is generally useful because it enables all kinds of sticky stuff that historically has been difficult, and which seem like the sort of things that should be easy. Most people would expect to be able to plug a USB headset into a laptop and have it "just work." Older approaches like ALSA were designed for a more static world. It isn't unlike CUPS. Sure, if all you need is to occasionally print to a postfix printer on a serial/parallel port then you don't really need it. However, for just about everything else it helps quite a bit. Software usually gets written and becomes popular because it scratches some kind of itch. If there is software that you don't care for, I suggest learning how it works anyway. Knowledge is power. Besides, you never know when you'll need to evesdrop on somebody in an emergency... :) -- Rich
