Hi, I will start with a TL;DR summary of my mail: we don't have to sandbox our xdg-apps, like you say. But if we do, we should only allow running sandboxed apps, even if it means we lose most of our apps. Otherwise, the sandbox is pointless. It's a hard choice we'll need to make. Right now, we're headed towards developing a useless sandbox, which is silly, and it's time to apply the breaks and rethink that. On Fri, 2015-09-11 at 07:02 -0400, Josh Boyer wrote: > That's ignoring the existing security measures we have in place, like > RPM/dnf requiring signatures on packages This isn't true; you can install unsigned packages whenever you want, just by clicking through (well, keypressing-through) the warning from dnf. If you've installed RPMFusion, you've done this. > and SELinux. SELinux is very important, but the security model is completely different: it's designed to protect benign but buggy applications from being owned by malicious input. We're trying to protect against applications that are themselves malicious. The malicious app is simply not going to ship with an SELinux policy that constrains it from doing the bad things it wants to do. Actually, it will not ship with an SELinux policy at all, because it's not mandatory to write an SELinux policy, so nobody does. Let's agree on the attack model before we continue the discussion: the attacker's goal is to read some file it's not supposed to from the user's home directory. It's not trying to find some kernel exploit for privilege escalation, because it doesn't need any privilege escalation: it can do all the bad things it wants to do without that. Stopping it requires xdg-app, or a similar technology, or a very restrictive default SELinux policy that breaks everything (which is worth considering). > Sure, if users > force install everything then yes they can have their systems owned. > This has always been true and xdg-apps doesn't present a new wrinkle > at all here. The goal should be to make it sufficiently difficult and scary to force install things that a large majority of users will decide not to, but you still can if you really want to. > I think you're taking too hard a line on this. Yes, possibility > exists for people to screw up their own machines. It will always > exist. That doesn't mean the infrastructure we have today and the > xdg-apps work being done is worthless. > > I'd also contend that users don't care about xdg-apps. Really, they > probably don't. If you tell them it will run anywhere and it's > sandboxed they'll say "oh, that's cool" and then get back to using > their app. The group that gets the majority of the benefit of xdg > -app > is developers because it makes publishing their work in a secure and > well supported way even easier. > > So I don't really agree with your BS assertion on either side. The > compromise is pretty simple. We provide applications in Software > because Software exists to show users what applications can be > installed. It shouldn't matter what deployment technology the apps > use, as long as they come from a trusted source. That's one possible choice for us. We can do it. xdg-apps still provide good benefit for developers as a cross-platform way to deploy applications. But then there is no point in sandboxing the xdg-apps, because the optional sandbox doesn't protect users, and it's inconvenient for developers, so it's more harm than good. We'll miss out on the tremendous security benefits of sandboxed applications. That's a valid choice for us to make, though. It might be the best choice, because there is a huge cost to pay in losing existing apps if we want to mandate the sandbox! It's going to be hard -- perhaps unrealistically hard -- to tell developers all their apps have to change, and to tell users old apps can't be installed anymore. But if we don't do that, we should give up on the plans for sandboxed applications, because it's also unrealistic to expect malicious applications to use the optional sandbox. We could define some subset of applications that are allowed to not use the sandbox, say all the existing packages in the Fedora repositories, but it's not hard to get a malicious application into Fedora, or take a non-malicious application and make it malicious, so again, the sandbox provides only quite limited benefit. (We're completely reliant on our upstreams and our packagers to never add bad stuff.) > If you want to make non-sandboxed apps more secure, then perhaps work > could be done to create sandboxes on-the-fly for regular RPMs. That > would be difficult, but it would provide an added layer of security. > It wouldn't necessarily be an xdg-app as that is more than just > sandboxing, but creating a new namespace/Docker container for apps > during RPM install might be possible. This might well happen, but it can't work well. The thing is, either applications require changes to be useful when run in the sandbox, or the sandbox isn't good enough. LibreOffice isn't going to be a very great app if it can't see any of your files when you run the file chooser, and if the files it saves can't be accessed by other apps. And the sandbox is worthless if it lets LibreOffice access files without going through the file portal. But I argue that's the fate that should await applications that aren't ported to use the portals provided by the sandbox: apps should be sandboxed automatically, even if the result is that they're broken. I'm picking on LO just as an example; Alex already has a working demo of LO using the file portal. The big apps will be taken care of by developers who care; it's the smaller apps that will be out of luck. But then we lose users when their old apps don't work properly. Or we lose users because we didn't let them run the old apps at all. Michael -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
