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.