[ubuntu-hardened] SNAP Oddity Occurrence

[Tom Bronkema]

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/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/20221028/96906dca/attachment.html>