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 |