Why isn't 1Password sandboxed?
In 1, danco said that the differences between the App Store version and the agilebits.com version are "None, nowadays, except for the licencing and payment structure".
In 2, though, brenty said "they store the data in different places, since the App Store version is sandboxed". (I've confirmed what brenty is implying here: my direct purchase of 1Password.app is not sandboxed.)
From what I've found, the App Store version used to be more powerful: it had iCloud integration, back when that was an App Store-only feature. So there was never any technical reason I see for the app to not be sandboxed.
Why is the agilebits.com version of 1Password not sandboxed? It seems that would be a great additional layer of security to have. I'm a little worried I bought the insecure version now.
1Password Version: 6.5.3
Extension Version: Not Provided
OS Version: macOS 10.12.1
Sync Type: Not Provided
Comments
-
Why is the agilebits.com version of 1Password not sandboxed? It seems that would be a great additional layer of security to have. I'm a little worried I bought the insecure version now.
@Will83921: Great question! The short answer is that your 1Password data is end-to-end encrypted, so 1Password doesn't depend on this for its fundamental security. After all, not all platforms (or OS versions) support this in the first place...which brings me back to the beginning. When we talk about sandboxing, there are a few things to consider:
- What does sandboxing mean in this context?
- What are the benefits to 1Password users?
- What are the drawbacks?
What we mean when we talk about sandboxing on macOS
I think that #1 is important because when a lot of folks hear "sandboxing" either they get a confused look (who comes up with this stuff anyway?) or they think it's the same as, say, iOS apps. Sandboxing on the Mac, though, is fairly limited. It's something that's enforced at a comparatively high level (as opposed to iOS, for example). Sandboxing on macOS means that an app essentially agrees to limit itself to its own corner of the disk, and that it declares specific entitlements for everything else it wants to do (network access, etc.) And in the App Store review process, Apple checks to make sure that this contract is adhered to. But there are always exceptions.
Why it doesn't matter that 1Password for Mac isn't fully sandboxed now
Given that macOS (née OS X) wasn't designed with any of this in mind, the default permissions for apps is full access (apart from SIP in El Capitan and Sierra, which protects system files). So sandboxing restricts the sandboxed app from accessing data elsewhere in the system, but not other, unrestricted apps from accessing it. I guess in a nutshell, sandboxing 1Password for Mac could help protect you from 1Password, but not 1Password from something else. And if you're not willing to trust 1Password, you probably wouldn't be using it to store your most sensitive information. If all Mac apps were sandboxed, then that would change things, but that isn't even close to becoming a reality.
Why 1Password for Mac may be sandboxed in the future
Finally, as I alluded to above, the Mac App Store version of 1Password isn't fully sandboxed either. There are exceptions so you can do things like sync your data with Dropbox (or an arbitrary folder,) integrate with browsers, and keep 1Password mini running in the background to facilitate those. That's taken for granted by classic (lowercase "c") Mac apps, but it's something we need special permission for from Apple to be allowed in the App Store.
1Password for iOS is fully sandboxed, but it can get some of this functionality now since Apple has added things like iOS Extension APIs and limited background processing. But even with those advances, the mobile app is much less capable in some key ways than what we're accustomed to on the desktop. But if Apple continues to make iOS more powerful, they may have macOS meet it halfway by enabling more similar capabilities that could allow apps like 1Password to truly be sandboxed without giving up core functionality.
Additionally, it would just be easier for us if we could build a single app on macOS. We're relatively close to that right now, but we do have to have some differences between the two, both for sandboxing, and to support licenses. If we could get everything we need to build a single app that could legitimately exist in either "world" without modification, that would be slightly more convenient.
Keeping 1Password secure on macOS today
One thing I wanted to talk about is some other things we can — and do — do on macOS to keep 1Password secure for you that actually make a difference today. It's important to keep in mind that sandboxing can't protect 1Password from malicious software on your computer. But its encryption protects your data from being accessed by other apps, even in the absence of sandboxing. Your Master Password is needed to decrypt it after all. That said, installing untrusted software puts your data at risk when you do access it, since it needs to be decrypted for that to happen.
However, 1Password for Mac, regardless of where you purchase it, is cosigned by both AgileBits and Apple to validate that it's from a trusted developer and has not been modified. This also ties into Apple's Gatekeeper security feature. As a user, you probably won't notice anything because a legitimate, signed copy of 1Password will run without complaint. But I think most of us are familiar with the "unknown developer" prompt from unsigned apps, which you won't get from 1Password as a result. So in today's (Mac) world, using signed apps from developers you trust is a more reliable way to protect yourself, since a malicious app can target other apps regardless of their sandboxing status...and macOS itself is permissive by design. That offers a lot of power, and with great power comes responsibility (and risk, unlike installing 3rd party apps on iOS).
Anyway, I hope I've answered your questions reasonably well and given you some insight into where 1Password has been, where it is today, and where it might be going down the road. Be sure to let me know if you have any other questions. :)
0 -
Hi, brenty,
Thanks for the response. Unfortunately, I feel like a lot of this falls into the category of technically true but not really helpful.
There's a concept in security called Defense in Depth. I understand that my 1Password vault is encrypted, but that doesn't mean I'm going to post it in a public place and depend on this encryption for all my security needs. Yes, I trust that AgileBits has a bunch of smart and hardworking programmers, but remember Schneier's Law: anyone can come up with encryption system they can't themselves break. Layers of security are good. The macOS sandbox isn't perfect, but it also isn't useless, even for an application you trust with your passwords.
Does AgileBits vouch for every instruction being run in the 1Password memory space? For example, 1Password fetches favicons from the network and displays them on screen. I assume this uses system libraries. In every release of macOS that I've seen, for several years, there has been at least one "Processing a maliciously crafted ___ may lead to arbitrary code execution" item in it. I'm having to trust a lot more than just AgileBits programmers here.
I would love for 1Password to have as few permissions as possible. That's the Principle of Least Privilege -- another core security concept. (Heck, I'd give up favicons, if I could be guaranteed that it could never touch the network, or try to parse an untrusted bitstream. I know AgileBits would never do that, though.)
Yes, it's true that not all platforms that run 1Password support sandboxing, but I'm not sure how that's relevant. As the most recent AgileBits blog entry said:
"But it would be foolish to not take advantage of some security feature available on one platform merely because such features aren’t available on others. So we are happy to begin to offer this additional layer of security for those of our customers how [sic] have computers which can make use of it."
At the start of your response you listed 3 relevant questions, and discussed #1 and #2 at length, but I don't see any mention of #3. Is there any reason you don't just flip the switch and do it? You may find the upsides to be minimal, but what's the downside? We know that it works and is perfectly usable, because all your App Store users already use it that way.
Thanks,
0 -
At the start of your response you listed 3 relevant questions, and discussed #1 and #2 at length, but I don't see any mention of #3.
@Will83921: I'm sorry for not answering each point directly, but rather as part of my overall response, and any confusion that may have caused. I directly answered the question you yourself posed at the beginning ("Why is the agilebits.com version of 1Password not sandboxed?" Sandboxing doesn't protect your data; encryption does), as the main point, since I wasn't sure how interested you'd be in the rest, but I'm always happy to elaborate. I'm just sorry that you didn't find the other information I provided helpful. I'll try to do better. Here's what I think you're looking for:
3) What are the drawbacks?
Is there any reason you don't just flip the switch and do it? You may find the upsides to be minimal, but what's the downside? We know that it works and is perfectly usable, because all your App Store users already use it that way.
I tried to make this clear in my previous reply, but it sounds like didn't achieve that, perhaps because I misunderstood the angle you're coming from, and that I tend to meander. :(
Why not?
For the purposes of 1Password for Mac's security, sandboxing does not provide a benefit, since any other standard Mac app can effectively access any data on disk. The Mac App Store version supports this because sandboxing is a requirement to be in the App Store.
Sandboxing 1Password only prevents 1Password from accessing data outside of its own sandbox...and again, if we're malicious, we could do that anyway with the AgileBits Store version, and get away with it with the Mac App Store version as well if we're able to sneak this through Apple's review process. Therefore, sandboxing would protect other apps from 1Password, but if any app is malicious, it's better not to allow it in your system it in the first place. Certainly we'll continue to consider doing this in future versions, but it isn't a change that would happen overnight. But we also have to be realistic about what threats this change protects against, and since the answer is "1Password" it seems like us offering a "sandboxed app" doesn't do much good if 1Password cannot be trusted in the first place.
So the downsides are that making this change wouldn't be trivial and that it doesn't offer a real benefit to 1Password users. If it did, we'd have done so already. We could have written a blog post about it and told you that it was "more secure" since sandboxing is in principle (as you rightly point out), but in practice, in today's macOS ecosystem, it isn't. We don't want to give anyone a false sense of security or enact "security theater", whether intentionally or inadvertently. So again, this is probably something we'll do eventually since, if nothing else, it makes it easier for us to not have to give different instructions based on where you happened to purchase 1Password for Mac. When the benefits outweigh the costs (and we can think of security as having "infinite weight" when it comes to 1Password, since it has to come first), it will happen.
Does AgileBits vouch for every instruction being run in the 1Password memory space? For example, 1Password fetches favicons from the network and displays them on screen. I assume this uses system libraries. In every release of macOS that I've seen, for several years, there has been at least one "Processing a maliciously crafted ___ may lead to arbitrary code execution" item in it. I'm having to trust a lot more than just AgileBits programmers here.
That's right. While we take responsibility for what 1Password does on its own, obviously if your machine is compromised and an OS bug exploited, all bets are off. You need to trust the OS (and the silicon it runs on) in the first place, but you're kind of doing that by virtue of using the system. We all are, since none of us are fabbing our own chips or writing our own kernel — Linus notwithstanding...but I don't think he's a 1Password user. ;)
Yes, it's true that not all platforms that run 1Password support sandboxing, but I'm not sure how that's relevant. As the most recent AgileBits blog entry said:
"But it would be foolish to not take advantage of some security feature available on one platform merely because such features aren’t available on others. So we are happy to begin to offer this additional layer of security for those of our customers how [sic] have computers which can make use of it."
Indeed. As I mentioned previously, Sandboxing is not a feature of macOS (as it is iOS); it is a feature of some Mac apps, and one that's supported as a way of getting into the App Store. That's what I meant by "not all platforms support sandboxing". I feel like Apple would love to have this be a core macOS feature, but I'm not sure how they get from here to there given its legacy, but certainly they've been trying to move in that direction. The one thing that seems perhaps achievable would be to require all apps to be sandboxed and distributed through the App Store. That's almost the same, but the underlying OS is still very much open...and a lot of Mac users would really hate that happening.
Anyway, I hope this makes up for the deficiencies of my previous reply, but be sure to let me know if you have any other followup questions. :blush:
0 -
For example, 1Password fetches favicons from the network and displays them on screen. I assume this uses system libraries.
Actually, it is my understanding that 1Password does not fetch favicons or initiates any other network communication except with AgileBits own servers. Is that correctly understood?
0 -
That is correct, favicons aren't fetched from websites to populate the icons on the various items in 1Password. Those icons come from our rich icon server and are higher resolution than what most websites provide in their favicon files.
1Password for Mac will interact with iCloud if you have that configured for sync. Dropbox sync on the Mac is entirely a local filesystem operation which is why the Dropbox application is required to be installed and running in order for that to function.
Rudy
ref: OPM-588
0 -
- Is there any reason you don't just flip the switch and do it?
Yes. It's not just a switch flip. You're technically right that enabling it is literally a checkbox to check these days... but that doesn't accurately represent the work that would need to happen on our end in order for users to transition over.
Let's go over just some of the thorns.
Broken Updater
Users rely on 1Password's built-in updater to update itself. That updater needs read-write access to an arbitrary location on disk (wherever the 1Password app bundle is living) in order to perform its duties, which it wouldn't have when sandboxed. This means that we would have to rework our updater to push the disk management components into an XPC service that is itself not sandboxed. If we used the Sparkle updater framework we could use the variants of it which do this, which I've done in other apps that I've worked on. But we don't use Sparkle, our updater is built in-house so we'd have to do that work ourselves. In the end you've got an app that's sandboxed but reliant on an unsandboxed service with arbitrary disk access. Is that significantly better?
Data Access Migrations
Existing users have sync setups that point to arbitrary paths on disk. When the newly sandboxed app comes up for the first time, we would need to perform migrations for these. That would involve having the user select paths for us so that we can create security scoped bookmarks. If they choose the wrong path, or decide not to choose a path... sync is broken and our inbox is in flames. There would be ways for us to mitigate this of course... it just requires more work.
Loss of Compatibility With Older Versions
I can take my 1Password 6 database, and still run 1Password 4 against it. If we sandboxed and moved our data into our sandbox, that compatibility would be lost as 1Password 4 doesn't know to go looking in a container for data. Every now and again you find a reason for needing or wanting to do something like that.
Cutting Out Possible Features
There are some features that we've looked at adding that simply wouldn't work in a sandboxed environment. I'll give you an example to make this more tangible. It would be nice if when 1Password decrypted attachments and documents that it wrote the decrypted files to an encrypted mounted disk image such that when 1Password locked the disk image would be unmounted and trashed. This way disk undelete utilities wouldn't be unable to get to any of that data. I could build such a feature in an unsandboxed app, but there's no sandbox exemptions that I can use, not even temporary ones, that would allow this to work within a sandboxed process. Bugs have been filed with Apple.
If we were to build 1Password from scratch today, our webstore version of it would be sandboxed. None of what I mentioned above makes it impossible to do, it would just take a bunch of elbow grease. Internally, we dislike that there's this difference between the two versions of the apps. We want to sandbox it if only for consistency. But doing that transition isn't easy. It would be much easier to do at a point where we can force a bit of compatibility breakage, like alongside a major release.
0
