Anybody know whether there is any initiative to certify Snap packages as non-Windows “infected”, meaning the code within the snap contains ZERO Windows code and neither includes, nor calls upon, any Wine or CrossOver libraries ?
I fear snaps becoming a mechanism for the pro-Windows camp to “de-stabilize” the Linux market by introducing FUD via snaps as Trojan Horses for all the ailments that expose Windows to malicious code!
In saying that, I don’t think that I am being overly paranoid.
Should those publishing Snap packages be required to allow the download and visual inspection of the list of ALL files contained in those Snap packages before any attempt to download the Snap packages themselves? (my paranoid streak again )
For one, I am not sure what you’re worried about. How is Windoze code going to impact an app? I’m not a fan of snaps in any case, but Windows isn’t Linux and Linux isn’t Windows. What’s the benefit of adding Windows code to a snap package? Am I missing something here?
I see some snaps have “[WINE]” included in their name; but I doubt that’s a requirement.
Snaps provide a certain degree of sandboxing, and there are a number of security mechanisms provided by Linux (e.g. user privileges and AppArmor amongst others) even when running Windows code via Wine. But ...
... it’s possible for a snap to be a malicious package even without attempting to access the system; e.g. the fake Exodus snap packages, see: Just been scammed by a app on the App Center.
Simply going by "does this use Windows API calls emulated via Wine" is not going to be a good measure of whether a snap is safe to run. I haven’t tried many, but anti-virus software seems like a more practical approach (e.g. ClamAV). If anyone has any recommendations or experience with anti-virus for snaps (or other software) I'd like to hear more.
I'd also add that often .deb packages fail to pass lintian's tests; are they safe to run? That's hard for a regular user to tell. I remember there was a whole debate about chrome-sandbox and unprivileged user namespaces (Ubuntu specifically, I think) that is probably still raging to this day.
I appreciate what you are saying, Fred, and you are correct about that.
However, I think you missed the “loophole” that Snaps provide as a mechanism to “flood” the Linux ecosystem with Windows-originating apps that are not bullet-proof to, or already infected by, malicious code.
If the snaps then include the vehicle which allows them to “bypass” security (via Wine/CrossOver), who is to say what damage those could wreak on a system! And maybe I don’t understand fully the limitations of Wine or CrossOver, but given the way Win code sometimes need direct access to the CPU/MB/Kernel, it certainly has me very concerned with the potential for disaster.
Stephen, are you implying that the “sandboxing” offered by Snap is like a highly-optimized and distilled version of Xen or VMWare ? Or is it something else?
As for ClamAV, I still don’t have a firm grip on what exactly it is doing for a “pure Linux” environment that has no Wine or CrossOver equivalent … unless you are telling me that there are Windows-oriented APIs already installed from the basic UbuntuMATE distro without my knowing/choosing to install them?
Are you also saying that Debian packages downloaded from a distro-specific repository could have embedded Win-related coding … without the Disto/Repository Administrator, or the End-User, knowing about it?
No, sandboxing is assumed to limit access of sandboxed application to the rest of the system, to a degree, of course. It is not a virtualisation per se. Surely, one can consider virtualisation to be a kind of sandboxing, but not vice versa.
@ericmarceau, I’m not even sure why I’m participating in this discussion, as I’m not running my Linux computer as a desktop/laptop and so I don’t need the plethora of apps. Thus, I haven’t found a need for WINE (and I’m a Mac user for personal computing) -or- Windows.
I’m not sure what Windows code would do to a Linux box. Windows is an OS. Not a very good one, IMO, but attempting to run Windows code, PowerShell, or any of that crud would likely not have any effect, much less work.
Not to dismiss the possibility of malware, but it doesn’t take Windows code to infect your computer. That’s why clamav or similar products are necessary.
What I visualize, Fred, is that Microsoft (and its cabal of 3rd-party software providers), having recognized that Linux will sweep Windows aside … eventually, will undertake an initiative to pursuade their “camp” to migrate ALL their Applications into Android-like packages, in this case Snap packages, and announce at a near-future technology Expo, with a BIG splash, that
they have “ported” their entire Windows-based capability to a “future-looking” Linux-based architecture,
they have ported their entire suite of applications to the Linux environment in the form of Snap packages, and
their entire 3rd-Party Partner ecosystem has ported their own entire suites of applications to the Linux environment in the form of Snap packages, and
none of those have “cleaned up” their exposure to malware, thereby allowing the “Plague Ships” into the Linux ports and spreading the havoc!
Given how little Microsoft has contributed to Wine itself; this doesn't seem like something they are interested in.
Wine is not Windows.
Wine is a Linux program.
Specifically (in my words) it is a POSIXLinux-compatible implementation of many key Windows library and API calls; and it enables the execution of Windows binaries (e.g. executable and library code) on top of its abstraction of the Linux system.
Any security issues (or risks to the Linux or other 'host' OS) that are present because of running a Windows program using Wine are - by definition - security issues of the host and Wine.
Wine doesnt require root privileges; so one of the key security features of Linux (et al) is still intact when running Wine.
Anyway; my thoughts are more or less a) what you are hypothesising isnt likely to happen and b) there are risks as you describe but I dont think Wine and Windows programs in particular is going to make them significantly worse.
Stephen, I think you misunderstood my following statement:
By that, I meant that they would build their on layer (equivalent to Wine/CrossOver) on top of a Linux base, and, as Microsoft is prone to do, build its own flavours of APIs within the Linux ecosystem, claim they are better than all the rest!
Since the base will be Linux, they will pollute/dillute/confuse the definition of what Linux is, thereby causing the blurring of (losing sight of) the need for freedom and ease of Application Suite permutation and customization, and emerging from what I perceive would be their rapid takeover of market-share by facilitating Client-base migration for a small fee (say about $50 per desktop for everything without exception), because the base is pure Linux, they will then attempt to claim dominance over the Linux field on the basis that the number of “seats” having “their architecture configuration” will have reached numerical prominance.
What we have known as the world of Linux until now will … I fear … become a cherished past!
… and maybe I am overestimating the single-minded focus that Microsoft has for reclaiming/maintaining its position in the future “world order” of computing infrastructures!
I get the fear of the "embrace extend extinguish" paradigm; but I just can't see it playing out how you describe.
Microsoft's plan for getting Linux users back seems more along the lines of ... making their own 'Wine': the WSL. Instead of Windows users leaking to Linux because we can run Windows applications through Wine; they want Linux users to leak to Windows because they can run Linux desktops/applications with WSL.
You probably aren't underestimating at all; but I think you might not be correct about the approach that they'll take to get Linux users back.
In my view the much more likely - and existing! - approach is; 1) use courts and IP/patent laws to prevent Linux development, and; 2) apply pressure to hardware and other vendors to focus their support and development efforts towards Windows (making it harder for Linux to compete).
So … WSL is like a scaled-down, stripped-down Xen/VMWare, without being honest about it or calling it what it really is!
… AND … its misleading about expected levels of performance observed if running under that framework, because they are suggesting that there is NO overhead, which must be categorically false!
Correct?
(P.S. Just confirmed what I thought as true per someone’s actual experience described here! AND … according to another posting here, Snap and Flatpack don’t work under WSL!!! What kind of garbage is that? Proof positive that Microsoft does want to leach away Linux users by setting up a false performance comparison of Applications on a Windows/WSL combo box! Sounds like there is a need for a major campaing to educate people to avoid them being sucked into the “black hole” that the Windows ecosystem represents. )
Can you point to a link on the snapcraft site that makes a categorical statement to that effect?
What I’ve seen says it is only workable under WSL2 (I have no direct experience with it) and that is hamstrung by lack of systemd functionality! Do you know anything about that?
I think whatever experience that user had 3 years ago (that you linked in your post) reflected some obstacles with using snap that are long since ironed out.
I tend to agree with you stephematician. Windows already made the Linux subsystem to try to keep developers from going to Linux. It would seem that would be their focus more than changing Linux to be more like Windows. If MS screws up it will be their ever changing hardware requirements, which is probably seen as a good thing by MS as they are now in the hardware business themselves too, but starting to annoy people who have to throw out perfectly good computers.
)
Canonical partnered with Microsoft to enable systemd support; see e.g. the announcement