Snap and modern software (was: Remove /snap directory)

[Keith]

On 12/15/22 1:40 PM, rikona wrote:
> On Wed, 14 Dec 2022 14:04:54 -0600
> Keith <keith at caramail.com> wrote:
> 
>> On 12/14/22 11:43 AM, rikona wrote:
>>> On Tue, 13 Dec 2022 23:56:32 -0600
>>> Keith <keith at caramail.com> wrote:
>>>
>>> <BIG snip>
>>>> And of course snaps also allows you to run closed source,
>>>> proprietary software which cannot be included in Ubuntu
>>>> distributions.
>>>
>>> Perhaps also malware, tracking stuff, etc. Perhaps also easier to
>>> make it harder to find such stuff in the package?
>>>
>>> How do you protect yourself from bad snaps?
>>>
>>> I think there's some level of review, but I don't know how extensive
>>> it
>> is. Right now you can use the command-line snap tool to see if a snap
>> is verified to some degree. Green checks by the publisher name
>> confirms they have been verified by Canonical. From my observation, a
>> green check usually means the publisher is also the developer of the
>> software program, or a contributor to the project. Yellow/black star
>> badges by a publisher's name I believe indicates the publisher is a
>> verified snap packager.
>>
>> But really your concern is equally applicable to any source of
>> software distribution. How you do protect yourself from bad packages
>> hosted in an anonymous PPA?  How do you protect yourself from bad
>> Android apps that are in Google's PlayStore? For that matter, how do
>> you protect yourself from any bad packages in the Ubuntu archives?
>> There's literally thousands of packages in the combined repos. Can
>> you ever be sure that a few of those don't contain malware/spyware or
>> just badly written pre/post install scripts that can trash your
>> system because they're executed with root privileges? Do you vet
>> every package that you install on your system to make sure its not
>> doing anything weird? Do you trust your kernel?
> 
> Overall, a tough problem, as you point out. In part, I tend to trust
> completely open source stuff that is popular, with the idea that you
> code experts may spot something suspicious.

Here's a few links to articles that I hope will begin to disabuse you of 
the notion that just because software that is open-source, widely-used, 
and is produced by experienced developers is automatically trustworthy 
and safe:

https://www.linuxjournal.com/content/allegations-openbsd-backdoors-may-be-true

"If security risks of this magnitude are found it could undermine this 
long earned reputation and call into question the very concept of "many 
eyes." de Raadt said that the many eyes concept is very real, but the 
*Open Source working relationship is greatly based on trust and not 
every commit is reviewed.* [my emphasis] The wide sweeping effects of 
any deliberate security holes found in OpenBSD could very well be less 
trust and more review within Open Source projects across the board.

https://www.theregister.com/2013/09/19/linux_backdoor_intrigue/

"During a question-and-answer ‪session ‬at ‪the LinuxCon gathering in 
New Orleans this week‪, Torvalds ‬and his fellow kernel programmers 
‪w‬ere‪ asked by moderator Ric Wheeler whether America's g-men leaned on 
the Finn to compromise Linux's security, allowing spies to infiltrate 
computers.

Torvalds replied with a firm "no" while nodding his head to say yes, a 
response greeted with laughter fr‪o‬m the audience. He quickly followed 
up by repeating "no" while shaking his head in the negative."

"Rumours of backdoors and other forms of hidden access routes in 
Microsoft Windows, Linux and security protection products have 
circulated in infosec circles for years. Fresh revelations from NSA 
whistleblower Edward Snowden that US and UK intelligence have subverted 
key technologies have reopened the debate."

 From just last year:
https://www.theverge.com/2021/4/30/22410164/linux-kernel-university-of-minnesota-banned-open-source

"Some developers rejected University of Minnesota researchers’ 
perspective outright, claiming the fact that it’s possible to fool 
maintainers should be obvious to anyone familiar with open-source 
software. *“If a sufficiently motivated, unscrupulous person can put 
themselves into a trusted position of updating critical software, 
there’s honestly little that can be done to stop them,”* [my emphasis] 
says White, the security researcher.

On the other hand, it’s clearly important to be vigilant about potential 
vulnerabilities in any operating system. And for others in the Linux 
community, as much ire as the experiment drew, its point about hypocrite 
commits appears to have been somewhat well taken. The incident has 
ignited conversations about patch-acceptance policies and how 
maintainers should handle submissions from new contributors, across 
Twitter, email lists, and forums. “Demonstrating this kind of ‘attack’ 
has been long overdue, and kicked off a very important discussion,” 
wrote maintainer Christoph Hellwig in an email thread with other 
maintainers. “I think they deserve a medal of honor.”

 From early this year:
https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034

"Successful exploitation of this vulnerability allows any unprivileged 
user to gain root privileges on the vulnerable host. Qualys security 
researchers have been able to independently verify the vulnerability, 
develop an exploit, and obtain full root privileges on default 
installations of Ubuntu, Debian, Fedora, and CentOS. Other Linux 
distributions are likely vulnerable and probably exploitable. This 
vulnerability has been hiding in plain sight for *12+ years* [my 
emphasis] and affects all versions of pkexec since its first version in 
May 2009 (commit c8c3d83,  “Add a pkexec(1) command”)."

Lots of eyes have looked at polkit, worked on polkit, and yet a critical 
vulnerability that's been present in pkexec(1) since its first commit 
went unfixed for 12+ years even though it had even been analyzed 9 years 
earlier. But nothing was done at that time by the developer because the 
bug reporter wasn't able to come up with a working POC exploit back then 
and so was ignored.

  And, the compiled code was
> produced from THAT source. 

As I asked in my previous response, do you do that level of vetting now 
with software obtained from other sources? I doubt it. You implicitly 
trust Canonical, the Ubuntu community, and by extension Debian since the 
vast majority of the software in the repos of any release came from 
Debian unstable. But, for some reason, you won't trust Canonical when it 
comes to offering snap packages through a software distribution store 
that it exclusively controls. If you don't trust Canonical, why are you 
running Ubuntu?

Snaps seem to be much less transparent. Did
> they use some library from country X just because it was more
> convenient? Or some call-home Google tracking code because it is faster?

> Perhaps I need to understand the 'verified' process better, to know
> what exactly has been verified.
> 

What's been verified is that the people publishing snaps are who they 
identify themselves to be. If you install the Spotify client snap, you 
can be assured that the software was developed by Spotify company, 
packaged as a snap by the Spotify company, and published to the Snap 
store by the Spotify company. Now whether to trust software from Spotify 
is going to be a leap of faith for you unless you get hold of the source 
code and have it analyzed for problems. Then you'll want to compile 
Spotify's source code in such a way as to create a reproducible build 
that can withstand a byte-for-byte comparison with Spotify's version to 
make sure that the binary program that Spotify offers in the snap store 
is the same as the one that you created from their source code. You 
could run the Spotify program you just compiled, but you'd have to go 
through the same procedure everytime a new release comes out. Rather 
tedious, but you gotta be sure.

   And then, you'll have to trust that the underlying OS and/or firmware 
for your system hardware that your running the Spotify client on are not 
performing code injection of a routine that causes the client to send 
copies of your playlists, credit card information,  etc. to some bad 
actor in Bulgaria.  To prevent that though, you'd need to the same level 
of vetting on your OS and hardware that you just did for the Spotify 
client.

And where to begin to do that? The kernel, obviously as the linked 
articles above would mandate. Maybe that big ol' linux-firmware package 
full of unauditable binary blobs that makes your hardware devices work. 
I guess you trust hardware vendors from foreign countries like China to 
provide non compromised firmware, right?  Of course, there's the cpu and 
chipset microcode to consider, especially with Spectre and other 
exploits of mostly Intel cpu vulnerabilities out there.  Oh, and if you 
plugged in any usb devices into your system, you'll probably want to 
check to see if they've surreptitiously flashed the usb controller 
firmware, or hard drive firmware, or whatever else is flashable on your 
system to load undetectable spyware on bootup. Bad, bad USB.

Trust is the key here. Who do you trust?

-- 
Keith