[ubuntu-hardened] SNAP Oddity Occurrence

[j.son at e.email]

holy shit! This is the type of thing that I trust is always around the corner if not already present. Unfortunatelyu, I have little ability to positivitily identify and ask for help appropriately.. How does one go about ensuring that this type of breach is not possible? Sounds like an amature question but would like to hear the perspective from this community level.. 
Cheers, and HH!
October 28, 2022 3:18 PM, "Tom Bronkema" <bronktru at gmail.com (mailto:bronktru at gmail.com?to=%22Tom%20Bronkema%22%20<bronktru at gmail.com>)> wrote:
I left music running in Youtube on Firefox [Firefox 106.0.1 (64 bit) - Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0] on my Jammy machine last night. This morning, woke to find the music paused, the user account locked out, with a splash screen showing for a snap user agent session that was opened remotely, with it demanding I type in the system administrator password to continue installing (?) some unidentified snap update. Thanks, but no thanks. That occurring appears an obvious high potential for abuse in a password harvesting scheme, more given unidentified automatic updates coming out of the blue that I have no control over ?

I opted instead to try to shut down the system... which it also did not want to allow me to do without entering the password.

Snap and related "push" driven change is inherently insecure... as it requires (every employee within) the entire trusted ecosystem must be perfectly trustworthy to be secure, which is impossible. That glaring "social" flaw was exactly the basis of the massive breach of trust in the prior Solar Winds hack that was revealed just prior to the last election... which I was first to discover by virtue of having been made a specific target of an "Russian" operation being conducted within that exploit as an attack... and a bit of luck in my analysis of what was occurring.

In Ubuntu it seems there is STILL no reliable logging of snap updates ? Today, I tried to see what the history of prior snap implemented auto updates was... and the relevant log file was empty. Snap update logging is inherently incomplete, or at worst, doesn't work at all... as the prior history of questions shows:

https://askubuntu.com/questions/920443/where-can-i-find-snapd-update-or-refresh-logs-how-does-snapd-inform-the-user-ab (https://askubuntu.com/questions/920443/where-can-i-find-snapd-update-or-refresh-logs-how-does-snapd-inform-the-user-ab)

https://askubuntu.com/questions/14328/where-can-i-look-up-my-update-history (https://askubuntu.com/questions/14328/where-can-i-look-up-my-update-history)

It is rational enough to address system security with automation in updates, but it naturally enables the risk of the automation itself becoming the conduit for systemic corruption. Pairing the automation (adequate for most retail users purposes) with an optional level of HARD admin oversight and control enabled where needed (as in critical nodes) should 1. give access control and 2. enable the full monitoring of ALL change activity occurring over all the avenues enabled in fostering changes. Those are the minimum necessary for enabling real security where it is needed. That is made vastly harder when there are multiple and overlapping update program routes or routines deb, dpkg, snap, flatpack, synaptic, software update, etc. which are each independently implemented and separately logged (or not). The benefit of efficiency in independence in change origination is entirely aggregated on the production side ? There is zero benefit of that independence in origins in the end delivery to a single target machine ? Destination nodes should not suffer functionally at all from narrowing the pipes to flow changes through a single local (logical) conduit. Otherwise it is nearly impossible to manage the risks or the problems that result, or to reverse engineer errors that are imposed through them, when some major changes are implemented without user awareness, and are not even being logged. The risk is amplified by the false sense of security enabled in the pretense that the routine automated update management systems, as the routine updates and security updates in software update, are inherently complete and and fully adequate to provide control in a secure manner. Ex: I have "display" updates selected for my update handling... yet still find updates are automatically downloaded before I select them ? What else is occurring that is not what I opted to enable ?

Along with greater end node control, a single master change log that is implemented across schemas might help... one that logs all "attempts" with tracking of origins even better. It need not disrupt separate logging of events in full detail under the ad hoc programs own self logging... but should co-locate the full view in a single log with at least a single line referencing each of the disparate events by all the means that are allowed in enabling changes... all in a single file. It won't stop any new Solar Winds type attack from inside the trusted systems, but it will dramatically improve the ability to recognize, isolate the origins, and respond to them WHEN they do occur.

What I want: A switch that allows me to opt to (isolate and) impose local admin control with yes/no permissions over every channel pushing updates... better explanations in plain text of purposes, as too many now have no explanations... and I want every one of those channels pushing updates forced to log its change attempts in a single log file. And, I want the systems control options I am offered to actually work as advertised... so files don't download themselves and attempt to take control of my machine when I've not allowed that.

I still have no obvious way of finding out what the attempted update was that opened the snap user agent session on my machine last night ? Perhaps it was Firefox, as it has a newer version. The tracks I can see in my system suggest it might also be an nvidia fabric related issue...

It is disheartening to note that since the last Solar Winds exploit... there appears to have been no serious re-thinking of the problem of "ownership" of access and control by those on the "trusted" side of the barriers being erected. Security CANNOT be imposed by control from the top down... but has to be a function of interactive access and permission controls at systems and local levels. The "trusted" side... cannot be trusted without a time sensitive process of validation of the legitimacy of changes before they are pushed. Routine updates are not made problematic by delay for validation... while the lack of local control over systems granted wide access given unquestioned trust opens routine changes up as a pathway for introducing critical vulnerabilities. The basic logic of security is broken in the result.

Fix it please ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-hardened/attachments/20221031/8aa0fb7e/attachment.html>