Linux Snap package tool fixes make-me-root bugs The snap-confine tool in the Linux world's Snap software packaging system can be potentially exploited by ordinary users to gain root powers, says Qualys. Snap was developed by Ubuntu maker Canonical, and can be used with Ubuntu and on other Linux distributions, if one so wishes, to install applications and services. According …
Even tougher on developer-users.
Snap, like other "app store" models seems to exist for the purposes of consolidation in the world of tech. Make it easy for big players to publish software, make it easy for the general public to ignorantly use that software in the way the developers intended (and only in the way the developers intended), but make it very hard for anyone to do something new that they want to do and the developers hand't envisaged (except install rootkits, apparently..)
The whole reason I like the Linux world is that I am not hostage to the will of some software developer (whose boss wants to monetize me, with a z) - most free software is designed for a flexible use case - take this software and do whatever you like with it; inspect the code, modify it, plug it into something else, run it on a microcontroller if you really want.
Whereas free (as in beer) software, sometimes with a token "open source, but not really" repo that lets you build absolutely nothing useful, and certainly not the distributed binary package that the developers offer to the public, is highly unscrupulous IMO. The tech world have been taking advantage of open source developers for years, consolidating their power and getting away with it.
The worst part is where this encroaches into education - I think that children are being prevented from learning how to code independently of some tech company's walled garden. Teach the kids how to use GCC, not bloody Android.
The other thing I despise about snap is that when I do a df -h command, it is filled with /dev/loop. I am thinking of moving away from Ubuntu because of the snap situation. How many gnomes do I need? I have about 6 gnome snaps taking up valuable screen space.
I don't want to do a df -h | grep -v snap as it's still annoying.
Virtual machines are not what you think they are.
A sandbox is not (or not necessarily) a VM. A sandbox is a process that is forced to drop capabilities before it starts.
A process is already isolated: It is restricted by user privileges, and it has access to only its own virtual memory. (And so do all the libraries and plug-ins it loads.). It communicates through signals, files, sockets, and sometimes explicitly shared memory.
A sandbox restricts it further by preventing it from opening new files. Or only files contained in one directory subtree.
A virtual machine is a processor, an interpreter, that is not made of silicon wires, but exists only as software. An emulator that emulates a machine that exists only in emulation. Hence: virtual.
A container is run and managed by a shell process that sandboxes it, but it still uses the same machine code interpreted by the same non-virtual machine under the same scheduling by the same operating system. No VM involved.
Yes! Just distribute the source and build it on the end-user's machine! They have plenty of computing power for it on any desktop or laptop, especially if the operating system includes `-dev` packages for libraries that you can just pull in. Even my phone is powerful enough to run a compiler.
It's open source software, after all! So show us the bloody source!
If not: What are you trying to hide? Maybe it is not so "open source" after all
I have a similar gripe with "manylinux .whl" files from PyPi. These are 'zip' archives, containing compiled binaries. I didn't know until recently that not all packages on 'pip' have source available. Some are under proprietary licenses.
"all work-arounds for problems you wouldn't have if you just compiled statically"
If any of the libraries you compile in has a vulnerability that won't be fixed by the user updating the shared version.
A better starting point would be to set the minimum dependencies as the oldest versions of every library that provides all the facilities you use.
Static compile? Why? Shared libraries solve so many problems, if something is broken you just fix the shared library and all the programs that use it are instantly fixed.
No Really! (ROTFL, my sides will be hurting soon).
One of the reasons I can tolerate "App Image" is it's basically a static compile. My problem with todays 'static compile' is unlike the static compiles of old where you used 'ranlib' and 'ar' files and only included relevant portions of the library... Today's static compile just includes the whole thing every time. So it's basically an App Image. Which could easily be done by putting all your crap in a folder tree somewhere, use (say) apparmor to restrict it's access to resources outside that folder, and set your library path local for specific copies of any highly volatile shared libraries you might be needing.
Kubernetes and Containers just creates another layer of bulls... to debug. I just had an argument with a fellow at work, that was struggling to define what a 'container' buys me over a tiny VM guest. Apparently another layer of management, with some flaky tooling is a "Good Thing". Apparently this somehow saves overhead, but I'll be damned if I see it in practice. It's basically a chroot type jail (which I'm not a big fan of either) built into a virtualized "container" that depends on the virtual machine, that depends on the hypervisor host, that depends on the hardware underneath.
IMNSHO if it needs that level of isolation, build a tiny alpine install, 2 cpu & 1G RAM, 1-2G disk, and run the application. Why invent a new wheel? Build a better guest management and deployment framework for kvm/vmware/whatever. Quit overthinking the problem. Stop solving problems we don't have with a new idea everyone should use.
Linux mint blocks it like this:
Create the file "/etc/apt/preferences.d/nosnap.pref", which contains (without <code>,</code>) :
<code>
# To prevent repository packages from triggering the installation of Snap,
# this file forbids snapd from being installed by APT.
Package: snapd
Pin: release a=*
Pin-Priority: -10
</code>
Seems to work in Ubuntu, also.
Just went to update one of my Ubuntu installs and got this, not encouraging.
Preparing to unpack .../12-snapd_2.54.3+20.04.1ubuntu0.1_amd64.deb ...
Unpacking snapd (2.54.3+20.04.1ubuntu0.1) over (2.54.2+20.04ubuntu2) ...
Setting up snapd (2.54.3+20.04.1ubuntu0.1) ...
Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ...
error: cannot read the state file: open /var/lib/snapd/state.json: no such file or directory
If the "Year of Linux on the Desktop" is ever going to happen then the problem of how to keep regular computer users from harming themselves through mistakes they make becomes much more of an issue. Containerized apps, in theory, are supposed to help with that. The "full technical write up" that you are supposed to read with a nice cup of tea (might require more than one to make it all of the way through) states that snaps were very hardened and it was hard to exploit them. It states that the first exploit won't work on a default Ubuntu desktop configuration, only a server configuration.
Do snaps discourage users becoming programmers? Maybe but I think most people interested in learning to program can still do it regardless of snaps.
Do snaps clutter the output of df? Try: alias df='df -x squashfs'
Hmmm, I just dumped my 92yro father's Windows 10 box that was a disaster and replaced it with a Debian 11, running KDE/Plasma, Firefox (Which has "all his programs on it"), LibreOffice (He cut his teeth on WordPerfect, this was a little painful), Thunderbird (Which he has used forever). He was stunned about how much faster it was than his old system. I set it up to "auto-vpn" over to one of my servers, and now I can just "RDP" over whenever I need to or use KDE screenshare. Zoom works as well, don't even need teamviewer anymore.
I cut the GF over to Kubuntu 18LTS years ago. I am safe to say she has had ZERO problems "harming herself thru mistakes she has made". I'm here to tell you, for most home desktops 99% of the time is spent in a browser. Frankly the only reason Window's is still relevant, is because it is the path of least resistance for the manufacturers.
I might mention all these boxes connect to my OpenLDAP server for authentication, and use Keepass backed to a private nextcloud server to store all their passwords. Now Openldap is decidedly non-trivial , and setting up the nslcd and sssd frontend's on the machines is not a 'user' process, but at this point the only reason you don't see more Linux on desktops is pure momentum, and the fact that way too many Windows Admins get lost if they can't click a checkbox. I've written more powershell as the Linux guy, than all of our Windows 'Administrators' combined. And I can't stand powershell. YMMV.
I got rid of Snap in Ubuntu after a fresh install of Ubuntu Desktop resulted in boot times in excess of 3 minutes. I got rid of the Snap crap and boot times went down to 34 seconds (times are from power-on to completion of login). I probably could have lived with the 3 minute boot-up process if the crappy Snaps would actually let me save documents to locations other than my home directory and I didn't have to deal with the 19 or more loop mounts. Did I mention Snaps are crap for me as an end-user.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
