On 161216-14:16-0500, Rich Freeman wrote:
> 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.
I'm not a match to you. My knowledge is insufficient. So I've taken
notice of your claims. 

However, these below, they need more of my time, than I can afford. If I
manage to understand some, I'll possibly comment/reply.
> 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.
I don't google. ddg.gg is way safer (the duckduckgo.com), way less
intrusive!

> >
> > 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.

It's not about me. And X11 can hardly be use for the purpose that I said
Pulseaudio is there for... So I'll just go on, for just a sentence or
two more, at the end of this message.

> 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...  :)

Oh, yeah, the itch! You bet! It scratches them where they think they
like, until they won't be able to deal with consequences... And it sure
is coming, don't worry (oh, I don't see the future, but the whole world
is a plane where things happen for reasons and consequences).

And, say, to use the parallel that I used in my previous messages to
this one, the majority of people don't even think about their
eavesdropper devices, they just use them, it's their itch that those
satisfy! Well, I don't, for one, and I don't care in among how
non-numerous I belong, but I am one of those that don't carry the
eavesdropper stinking itch-satisfier around...

So, without Pulseaudio, how would the shadows record, in such comfy
manner, globally, on everybody, as they, you don't dispute that, do you,
as they globally do record?

That's what you forgot to give your opinion about! I really wish
somebody replied to that! Do they do it? Not? And without Pulseaudio,
how then, in such comfortable manner?

There, the few sentences, but the topic really is serious, will Firefox,
from Firefox52, in my machine, and in people who don't want Pulseaudio,
like I don't want it, be silent really from Firefox52, as some Mozilla
devs of a ...particular kind, promised, repeatedly on that Mozilla bug
page.

> -- 
> Rich
> 

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Attachment: signature.asc
Description: Digital signature

Reply via email to