[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAC4ZH8DfBuQYVKFDBt93W+9k+2FTtqDZde78xNk4X54rX1wvZw@mail.gmail.com>
Date: Mon, 5 Oct 2020 17:57:28 -0500
From: Daniel Sprouse <daniel.a.sprouse@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: major changes if gnu/linux dominates the desktop
and/or mobile market?
I have to admit that as a unix/linux admin I have wondered how browsers are
able to skate by without their own unique no-login user, for security
purposes. It would make everything about them easier to control and secure.
On Mon, Oct 5, 2020 at 3:50 PM Solar Designer <solar@...nwall.com> wrote:
> 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
>
--
-- -- Sincerely Yours,
. Daniel Sprouse
Daniel Allen Sprouse
Unix/Linux Administrator
daniel.a.sprouse@...il.com
google voice: 512-815-2048
ne tectis a demergu, pater, formabis foramine in landa.
.
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.
