[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201005204820.GA8410@openwall.com>
Date: Mon, 5 Oct 2020 22:48:20 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: major changes if gnu/linux dominates the desktop and/or mobile market?
Hi all,
As a moderator I approved all messages in this thread so far, but I am
unhappy about the quality of both Georgi's message and the replies.
This is a valid topic, but there's no room in it for trolling (that's
how Georgi's message came across, even if maybe unintentionally) nor for
responding only about the presumed trolling. Just assume good faith and
post a response that's actually useful to others in here. I'll try:
On Mon, Oct 05, 2020 at 03:02:33PM +0300, Georgi Guninski wrote:
> Are there major security changes needed if
> gnu/linux dominates the desktop and/or mobile phone
> markets?
I'd say yes, major security changes are needed.
On the desktop, major Linux distributions (and by the way *BSDs and
Solaris are not very different in this respect, I think) when used as
single-user desktop systems lack security isolation between applications
of the user. (And also between the user and root, due to the typical
recommended use of sudo from the user account.)
This kind of security isolation is something we have on Android, but at
the price of the user not having full access to (not entirely) their
device. The user cannot even have e.g. a file manager app with which
they'd access all files of other apps.
Then there's the trend towards having a desktop-like Linux system on
mobile devices again. Before Android, we had e.g. Maemo and MeeGo. Now
we have e.g. Ubuntu Touch, postmarketOS, and Sailfish OS. As far as I'm
aware, so far this means lack of isolation between the apps just like we
have on the desktop.
We need the best of both worlds - isolation, yet full control. I guess
this could be achieved by devices gaining a physical button that would
need to be pressed at the time a newly installed app is to be granted
privileges by a component in the system's TCB. Said component would
also need to assure the user that it's the only one in control at the
moment (kind of after a SAK) and that the displayed privileges request
is truthful and complete, e.g. by lighting a dedicated LED. You want to
install an all-powerful file manager? Just wait for that LED to light
up, review what privileges would be granted to where, and press that
button to accept. Perhaps too cumbersome for typical users. Maybe an
alternative approach could be developed where a portion of the
touchscreen (or a secondary one) would be reserved for interacting with
the OS TCB. Perhaps something like MacBook Pro's Touch Bar could be
used for that purpose - and having that is already a precedent, it's
just not used for a security purpose yet (or I haven't heard of that).
Then there's the issue of attack surface and of few layers of security.
Linux kernel is quite poor in this respect when it comes to attacks by a
locally running program. Even Android doesn't change that. One way to
address this is to introduce a security layer between the (host) Linux
kernel and the program, running programs in VMs. This replaces the
attack surface with that of the hypervisor (and of the UI and components
needed to integrate the VMs back). Another (poor man's) way to
partially mitigate this is to have something watch and protect the Linux
kernel (Samsung KNOX, LKRG).
A desktop Linux distro that theoretically gets close to what's needed is
Qubes OS. It runs programs in VMs yet integrates them on a single
desktop. It effectively reserves a portion of the screen for control by
not letting VMs access full screen mode by default.
In practice though, there are severe security risks even with Qubes OS.
The in-VM systems need to be updated, and each update is a risk of
bringing in malicious code. When most VMs are based off the same Fedora
template, updating that means trusting all installed packages' Fedora
maintainers. Any package can gain full control through a malicious pre-
or post-install script, even if the software it installs is never
explicitly used in a given VM. This means instant access to all VMs on
next system restart.
For typical desktop Linux users, realistically most security is provided
by the web browser, which these days at least uses a sandbox, protecting
the user's files and other apps from itself. That's something the
underlying systems tend to lack.
> Remarks:
> 1. there was android malware on google play
Yet Android at least tries to limit apps to the permissions you approve
them to have, and isolates them from other apps (except for shared
storage of pictures and "SD card" if you agree to those permissions).
Desktop distros and desktop-like mobile distros don't even have that in
their typical usage.
> 2. ad-free and free as in beer android games are hard to find for us
I guess weird out-of-line things like that is part of why people think
Georgi was trolling.
> 3. we are pissed off by browsers accessing the microphone
> or camera (seen in the wild)
I don't know what this refers to, but I guess if unauthorized by the
user that would be a browser vulnerability or a modified malicious copy
of the browser (malware) or maybe active modification of a browser on
the system (also by malware).
Sure malware and social engineering are valid threats to keep in mind.
It's also a good idea not to rely solely on the browser's built-in
authorization checks, but to limit its access to system resources such
as the microphone and camera. Qubes OS does that.
> 4. reading $HOME might reveal more interesting stuff than
> root reading /etc/ (on debian 10 /home/loser is 755 and the
> default umask is 0022)
Now this is about the lack of security isolation between the users, if
there's more than one actual user on a system. I also do think this is
very wrong and needs to change (and is an easy change, unlike others I
pointed out above).
Relaxed file permissions like that may also further weaken some partial
sandboxes (when a service is running with its dedicated credentials, but
with retained filesystem access - such as because it needs that).
Then there are also plenty of other local security risks on typical
Linux distros, starting with risky data processing by apport and abrt.
Those would matter more if other issues I mentioned are addressed.
I might be right or wrong or (most likely) both, but I hope this sets
the tone for constructive further discussion.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
