Gentoo Archives: gentoo-user

From: Miroslav Rovis <miro.rovis@××××××××××××××.hr>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
Date: Fri, 16 Dec 2016 22:26:57
Message-Id: 20161216222708.GA23562@g0n.xdwgrp
In Reply to: Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No by Rich Freeman
1 On 161216-14:16-0500, Rich Freeman wrote:
2 > On Fri, Dec 16, 2016 at 11:51 AM, Miroslav Rovis
3 > <miro.rovis@××××××××××××××.hr> wrote:
4 > > On 161216-08:35-0500, Rich Freeman wrote:
5 > >>
6 > >> I'm not sure I understand what distinction you're making. I can't say
7 > >> I'm intimately familiar with the security model around Pulseaudio (at
8 > >> a glance it seems similar to X11 with its use of cookies, though
9 > >> obviously if you tell it to broadcast unencrypted multicast RTP on
10 > >> your LAN you'll get the obvious effects) but X11 has a couple of
11 > >> glaring security weaknesses. The most obvious is the fact that any
12 > >> random X11 client can read the keyboard input of any other client on
13 > >> the same server unless you jump through a bunch of hoops that I don't
14 > >> think anybody actually jumps through (though I do believe some of the
15 > >> X11 PIN entry programs may use them at least). Anything you type into
16 > >> an xterm could be read by your browser, and in turn by any code able
17 > >> to execute outside any sandbox that browser might have (root privs not
18 > >> needed for this).
19 > >
20 > > I don't claim it can not, but I doubt anyone can do it in my
21 > > grsecurity-hardened based Gentoo machine.
22 >
23 > As far as I'm aware grsecurity provides no protection against X11
24 > client evesdropping. This is an X11 "feature" and not an exploit
25 > per-se.
26 I'm not a match to you. My knowledge is insufficient. So I've taken
27 notice of your claims.
28
29 However, these below, they need more of my time, than I can afford. If I
30 manage to understand some, I'll possibly comment/reply.
31 > Here is one overview of the possibilities:
32 > https://pipefish.me/2012/08/28/spying-on-screens-and-keystrokes-the-dangers-of-open-x11/
33 >
34 > Any program that has access to your X11 cookie and which can connect
35 > to your X server (which includes anything actually displaying a window
36 > on your screen), can generally grab any of the keyboard input bound
37 > for any window on your screen. There are ways for programs to block
38 > this, but they're not super-practical.
39 >
40 > Amusingly enough I stumbled upon this blog:
41 > https://blog.separateconcerns.com/2014-10-24-cli-passwords.html
42 >
43 > This page "helpfully" suggests that you can secure your system by
44 > using a console pinentry program instead of an X11-based one, with the
45 > underlying assumption being that console software is more secure for
46 > this sort of thing. While the basic assumption is probably true, in
47 > this particular case it is definitely not. Entering a password on an
48 > actual virtual console or over ssh is in fact secure. However,
49 > entering it into an xterm (which is presumably what you're using if
50 > you would otherwise be using an x11 pinentry program) is absolutely
51 > not secure. The x11 pinentry program probably uses XGrabKeyboard to
52 > ensure that other clients can't evesdrop, while the console-based
53 > version doesn't know anything about x11. Some xterm implementations
54 > have a secure mode buried in the menus which turns on this mode which
55 > you can use to safely enter passwords, but almost nobody knows about
56 > this.
57 >
58 > There are a lot of "cargo cult" tips out there which are based on a
59 > lack of understanding of how software like X11 actually work. Of
60 > course, X11 is so convoluted that almost nobody actually understands
61 > everything about how it works, which is why Wayland has always been
62 > right around the corner. In general, though, it largely dates back to
63 > an era where people had rsh listening on all their hosts.
64 >
65 > >
66 > >> And I wouldn't be surprised if a lot of X servers still run as root
67 > >> for modesetting/etc.
68 > >
69 > > What user is that? It you want, tell me how to check it, and let's see
70 > > how spyware-prone my system is.
71 >
72 > If you don't have USE=-suid on your xorg-server package, then X is
73 > probably running suid root.
74 >
75 > In order to not have it run this way you need support for kernel
76 > modesetting. I was surprised when I found out that X11 even worked
77 > that way (we're talking late 90s here). It seems a bit like running
78 > pppd as root so that it can directly talk to a UART because you have
79 > an aversion to using /dev/ttyS*. In any case the kernel devs have
80 > generally been making the move to kernel modesetting so that your
81 > device drivers actually are in the kernel and not in random userspace
82 > programs (I'm all for microkernels, but not like this).
83 >
84 > If you don't have kernel modesetting enabled then X11 won't be able to
85 > run with -suid set. Google for gentoo kernel modesetting for a guide
86 > on how to enable it on most modern hardware.
87 I don't google. ddg.gg is way safer (the duckduckgo.com), way less
88 intrusive!
89
90 > >
91 > > It's been discussed over and over again. Lots of people are firm in
92 > > their understanding that Lennart is an actor by and for the big
93 > > business. Me too.
94 >
95 > Well, he is a Red Hat employee. Nobody really debates that.
96 >
97 > >
98 > > Whatever would anybody try to claim Pulseaudio code is, but to make up
99 > > for what was missing in some FOSS GNU Linux boxen for the missing
100 > > functionality that the big players couldn't otherwise get for their
101 > > Total Surveillance...
102 > >
103 >
104 > Uh, if the NSA wanted to spy on your box I doubt they'd do it by
105 > trying to sneak something into the open-source pulseaudio code that
106 > has numerous maintainers and which is copied all over the place.
107 >
108 > They'd probably just load some microcode into your audio hardware, and
109 > have it talk to some microcode in your NIC hardware, and if they
110 > needed some buffer they'd work it into your hard drive firmware. Then
111 > it works no matter what OS you're using at the moment, or even if you
112 > boot off of a DVD.
113 >
114 > And if they did want to do it more traditionally in userspace, they'd
115 > hardly be foiled because you aren't running Pulseaudio. They'd just
116 > modify your ALSA drivers or run a program that simply opens your
117 > microphone and sends the audio to some remote host.
118
119 It's not about me. And X11 can hardly be use for the purpose that I said
120 Pulseaudio is there for... So I'll just go on, for just a sentence or
121 two more, at the end of this message.
122
123 > In the end whether software works for you or against you largely
124 > depends on how well you understand how it all works. Don't get me
125 > wrong, there are lots of good reasons not to use Pulseaudio. I
126 > probably wouldn't run it on a server, unless it was something like a
127 > home music server. However, on a traditional desktop it is generally
128 > useful because it enables all kinds of sticky stuff that historically
129 > has been difficult, and which seem like the sort of things that should
130 > be easy. Most people would expect to be able to plug a USB headset
131 > into a laptop and have it "just work." Older approaches like ALSA
132 > were designed for a more static world.
133 >
134 > It isn't unlike CUPS. Sure, if all you need is to occasionally print
135 > to a postfix printer on a serial/parallel port then you don't really
136 > need it. However, for just about everything else it helps quite a
137 > bit. Software usually gets written and becomes popular because it
138 > scratches some kind of itch.
139 >
140 > If there is software that you don't care for, I suggest learning how
141 > it works anyway. Knowledge is power. Besides, you never know when
142 > you'll need to evesdrop on somebody in an emergency... :)
143
144 Oh, yeah, the itch! You bet! It scratches them where they think they
145 like, until they won't be able to deal with consequences... And it sure
146 is coming, don't worry (oh, I don't see the future, but the whole world
147 is a plane where things happen for reasons and consequences).
148
149 And, say, to use the parallel that I used in my previous messages to
150 this one, the majority of people don't even think about their
151 eavesdropper devices, they just use them, it's their itch that those
152 satisfy! Well, I don't, for one, and I don't care in among how
153 non-numerous I belong, but I am one of those that don't carry the
154 eavesdropper stinking itch-satisfier around...
155
156 So, without Pulseaudio, how would the shadows record, in such comfy
157 manner, globally, on everybody, as they, you don't dispute that, do you,
158 as they globally do record?
159
160 That's what you forgot to give your opinion about! I really wish
161 somebody replied to that! Do they do it? Not? And without Pulseaudio,
162 how then, in such comfortable manner?
163
164 There, the few sentences, but the topic really is serious, will Firefox,
165 from Firefox52, in my machine, and in people who don't want Pulseaudio,
166 like I don't want it, be silent really from Firefox52, as some Mozilla
167 devs of a ...particular kind, promised, repeatedly on that Mozilla bug
168 page.
169
170 > --
171 > Rich
172 >
173
174 Regards!
175 --
176 Miroslav Rovis
177 Zagreb, Croatia
178 http://www.CroatiaFidelis.hr

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No Walter Dnes <waltdnes@××××××××.org>