[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Oct 2020 13:22:49 +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,
This is a belated combined reply to what several of you wrote. I felt I
had to at least address Grant's request for me to clarify what I meant.
On Mon, Oct 05, 2020 at 03:53:26PM -0600, Grant Taylor wrote:
> On 10/5/20 2:48 PM, Solar Designer wrote:
> >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.
>
> I agree that there is a lot of room for improvement here. But -- like
> you say -- I don't think this is isolated to Linux by any stretch of the
> imagination. Unless I'm sorely mistaken, just about every contemporary
> desktop, and possibly server, operating system only gets as granular as
> the user level.
Sure. My mention of *BSDs and Solaris was in reference to other major
Open Source operating systems.
> >(And also between the user and root, due to the typical recommended
> >use of sudo from the user account.)
>
> Please elaborate what you mean here?
>
> Are you commenting on the use of sudo (vs other access control
> mechanisms) or the seemingly default recommendation to allow members of
> the sudo group run any and all commands via sudo? E.g.:
>
> %group ALL=(ALL) NOPASSWD: ALL
Neither. Rather, I refer to the fundamentally flawed approach of
elevating privileges from a user account that is also used for other
purposes. When doing so, you equate that account to the target
(elevated) one. Even if you have to enter a password (user's with sudo
or root's with su, which doesn't make a difference) when you elevate
privileges, you nevertheless expose the new privileged context and
whatever you had to enter to reach it to other programs running as the
user. You also have no reliable way to know that you're entering this
password to the intended program (such as sudo or su) rather than to
something the possibly-already-compromised user context might have
substituted in its place (e.g., a shell alias).
So the typical "best practice" approach of logging in as a user and then
sudo'ing or su'ing to root when needed is only good against mistakes and
a subset of attacks, but doesn't provide any guarantee (even assuming
perfect design and implementation of the system in all other aspects,
and the user resisting social engineering to the best extent possible).
So let's accept that the user account running the desktop environment is
root-equivalent security-wise (is only different from root for safety,
not security) as long as it's ever used to reach root.
Then our next logical step is not to run programs that are not an
essential part of the desktop environment as that same user account,
with the only exception being for whatever is used for accessing the
root account (and maybe other accounts) - e.g., there might be an option
to open a terminal window where you'd use sudo, or maybe even open a
root terminal right away (like Qubes OS has), maybe with password
protection for safety and for some loose security against
not-too-determined attackers with physical access to a live system
(although Qubes OS doesn't bother with that).
In other words, instead of having a seemingly unprivileged user account
from which you occasionally elevate privileges, acknowledge that you
actually have a privileged desktop user account from which you drop
privileges to run most programs and from which you occasionally access
root (without crossing a security boundary, but only a safety one).
Unfortunately, programs allowed to talk to the same X server that the
desktop environment uses are not really isolated from it. We need to
solve that. (Qubes OS does so by running separate X servers in VMs, but
the use of VMs is orthogonal to this. Poor man's solutions such as
limiting of X server features might also work, of course keeping the X
server with all of its attack surface in the TCB, which us unfortunate.
Then there's Wayland, which might also be part of a solution.)
Finally, we need to integrate those programs on the same desktop and
with ability to explicitly share files and clipboard. (Qubes OS does
this, too. A poor man's alternative or an intermediate evolutionary
step might be to run all programs other than the desktop environment as
just one other user account. This would address the issue of accessing
root securely, but wouldn't yet provide isolation between the user's
programs.)
> >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.
>
> I don't know anything about Android other than it made me mad the last
> time I tried to use it.
>
> I have seen some recent references to user namespaces and sub-IDs. I'm
> on the lookout for information to see if that might be a way to run
> different applications as their own sub-user-id and then behave
> similarly to how applications running as different users work. Meaning
> that each application -> user ID would have it's own files and would
> then rely on being a member of another group to access other files. All
> the while relying on file system permissions to protect other things.
>
> Aside: If you know of something that I should be reading, please point
> me towards it.
>
> Have Firefox run as <username>-<firefox> and Evolution run as
> <username>-<evolution>. Both user would appear as a different user than
> just <username> thereby enabling traditional user & group security
> models between applications run by the same user.
>
> I don't know if I'm hallucinating or if something like this is possible,
> or even done somewhere that I'm not aware of.
On Android, each app you install gets its own pseudo-user like you
describe. An issue is then being able to access one app's files from
another app when that is needed. This is typically achieved by apps
that sometimes need to share files requesting permission to access
global shared storage such as "SD card" (which is often just a partition
on the device's internal storage). This is not perfect: permission is
granted "just in case", not if and when access is needed, and it's not
granular. (I'm not familiar with how this might have been improved in
recent Android, though.)
On typical desktop systems, there's also the shared X server issue.
(That said, I've been running a customized system like this for years.
With my e-mail in Mutt, that one pseudo-user wasn't privileged to access
the X server, so couldn't e.g. capture my SSH key passphrases.)
> >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.
>
> I'm grateful that the web browser does do sandboxing. But I don't think
> that we should need to rely on it for as much security as we do.
Of course, better not to rely on one layer of security. I just point
out that the state of desktop OS security is currently worse than the
state of web browser security.
> >Sure malware and social engineering are valid threats to keep in mind.
>
> I don't see how the operating system / security infrastructure can be
> responsible for protecting people here.
The OS should at least provide a means for a knowledgeable user to
unambiguously determine where pop-up windows, prompts, etc. really come
from. (Such as Qubes OS coloring of window titles.)
> >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.
>
> I naively think that some of this can be controlled with traditional
> file system permissions on the relevant device files. If your (sub)user
> is not in the group to access the microphone -- guess what -- you don't
> get access to it.
I'm afraid, there's typically no way at the device file level to grant
access to audio output without also granting access to audio input.
Maybe this needs to be introduced into the kernel.
Besides, these days programs typically work through a server process
such as pulseaudio. In my example with having a dedicated pseudo-user
account for the desktop environment, that one could also control whether
audio input is enabled or disabled in the audio server, and the user's
programs would need to be disallowed to control that.
> >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).
>
> I want to agree with that. But, with things ultimately running as the
> same user, then any subdivision therein is difficult to enforce.
I was referring e.g. to Postfix daemons, some of which run with full
filesystem access yet as a (pseudo-)user that wouldn't be privileged to
access a user's home directory if the home directory and files inside of
it have stricter permissions than 755/644.
On Mon, Oct 05, 2020 at 05:29:20PM -0400, Stephen John Smoogen wrote:
> On Mon, 5 Oct 2020 at 16:49, Solar Designer <solar@...nwall.com> wrote:
> > 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.)
>
> I think it would take a lot of 'training' on why this is not wanted and
> setting expectations about how one is supposed to use a computer without
> that access.
Yes, the most difficult part with securing a desktop system is to keep
it conveniently usable. I think it is possible to isolate the desktop
environment from user programs without inconveniencing the user. As to
isolation between the user's programs, yes, that becomes visible to the
user and would require some training on how to explicitly transfer data
between the programs when needed. Perhaps there are ways to make this
intuitive, e.g. drag-and-drop.
> It is hard enough trying to explain to the person who wanted
> everything containerized for 'better' security that allowing them to ssh
> into the container so they can 'debug it' also removes the security that
> they wanted.
"Containerizing" things (at best) protects the outside from what's
contained, not vice versa. This is similar to the problem with sudo'ing
or su'ing to root, and requires a similar solution. This isn't hard for
the user if access to containers is managed from a preconfigured desktop
environment that's part of the TCB (like on Qubes OS), and that isn't
used to run unrelated programs in the same security context. The hard
part is integration of the isolated environments and learning when and
how to use it.
> > 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.
BTW, there's a Russian security-hardened fork of Sailfish OS called
Aurora. I've skimmed and searched its user's manual (in Russian) for
any mentions of isolation between the apps - found nothing, so I assume
there's none. (This isn't to say they haven't implemented any security
changes - I think they have. An interview I read with their CEO
looked surprisingly reasonable. However, it appears that addressing
cross-app attacks is completely out of their focus.)
> > 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).
>
> That would be useful and trusted if the touch bar has a direct path to the
> TCB versus being able to be reprogrammed by the OS.
Some components of the OS are normally part of the TCB (except in some
other contexts). Having dedicated screen space for control (like with
Qubes OS preventing VMs' full screen mode by default) or indeed a
dedicated screen is a reasonable security feature. And yes, there's no
security difference between dedicated screen space and dedicated screen
when they're managed by the OS, but that's OK.
On Mon, Oct 05, 2020 at 10:36:14PM -0400, Steve Grubb wrote:
> I will skip the whole discussion on access control. However to prove security
> requires going through a Common Criteria certification. The biggest issue is
> that the desktoptop uses dbus instantiation which does not have the auid of
> the requesting process. Meaning audit cannot work.
>
> The fix was kdus. That was rejected. But the issue remains. There cannot be a
> secure desktop without auditing. And no one is really pushing for a desktop
> certification, therefore no one is pushing to fix audit desktop problems.
I think it's a bit ridiculous to talk about audit on the desktop when we
haven't got the basics right. A typical desktop system user won't know
and won't benefit from audit, but would possibly benefit (ideally, not
having to know about it!) from isolation of the desktop environment from
other programs (e.g., as it relates to which programs can control the
audio settings).
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.
