Problems with Sandboxie

chrisparker_inv

@MikeT That did it! After turning off the code signature check, I don't get the errors for the websocket connection, and Agile1Pagent.exe does not run in the guest. It did try to run, but it doesn't have to apparently. More testing needs to be done on it, but its working more like it did before 4.6.1 than ever. Sandboxie doesn't change the signatures of any file, so this seems weird that this works.

What you see is what I see. I haven't done a procmon on it to get more info, but the fact that the path went ...Appdata\Roaming\Mo makes me think it is in a Mozilla directory.

AGAlumB

@chrisparker_inv: Ah, thanks for the update! I'm sorry for not at least mentioning that. 1Password simply won't be able to verify the code signature of something it cannot access directly, if it is outside of the sandbox with the browser running inside. Disabling the code signature verification also isn't something we like recommending for security reasons. In this case especially it seems counterproductive to the strict security you're trying to enforce with the sandbox in the first place. I'm glad that helped though.

chrisparker_inv

@brenty I don't know why it wouldn't be able to access it directly. Both Agile1PAgent.exe and Firefox.exe both exist outside the sandbox. The agent must see that the process trying to connect to it is associated with the anonymous user and not the user of the Agent process and declines to work with it. When the agent runs in the sandbox, they are both in running as an anonymous user and everything is happy. Seems like this is going beyond verifying the web browser's code signature.

As for the security risk, this is an issue of usability vs security for me. I think 1Password is much more usable when the Agent is running outside the sandbox. No worries about multiple processes reading and writing files, etc. No possibility of lost logins. I wish I didn't have to resort to this, but the outcome is a more reliable user experience. It would be nice if the this check were separated from the code signature check, so Sandboxie users could control it better.

AGAlumB

@brenty I don't know why it wouldn't be able to access it directly. Both Agile1PAgent.exe and Firefox.exe both exist outside the sandbox. The agent must see that the process trying to connect to it is associated with the anonymous user and not the user of the Agent process and declines to work with it. When the agent runs in the sandbox, they are both in running as an anonymous user and everything is happy. Seems like this is going beyond verifying the web browser's code signature.

@chrisparker_inv: Ah, you've hit the nail on the head! I should have mentioned this but glossed over it a bit since it was part of the discussion earlier. A while back (two months already?!) we added mutual authentication to 1Password for connections to the browser extensions expressly to protect against the type of attack you're describing: another user on the same machine connecting to 1Password to access data in your vault.

As for the security risk, this is an issue of usability vs security for me. I think 1Password is much more usable when the Agent is running outside the sandbox. No worries about multiple processes reading and writing files, etc. No possibility of lost logins. I wish I didn't have to resort to this, but the outcome is a more reliable user experience. It would be nice if the this check were separated from the code signature check, so Sandboxie users could control it better.

I agree that mutual authentication can be a bit of a nuisance in some cases, even when 1Password is used as intended (extension issues, browser updates, etc.) However, 1Password is, first and foremost, designed to secure our data to prevent anyone else from accessing it. So we feel strongly that both the code signature check (to validate the browser) and mutual authentication (to validate the connection with 1Password itself) are important. Hopefully in light of my comments above you'll appreciate why.

We don't have plans get rid of mutual authentication or make it possible to disable it, and it's likely that future versions of 1Password will not have an option to disable the code signature check either. After all, in general, the answer to the question "Who am I speaking with?" is critical, especially when sensitive information is involved. And with 1Password in particular, I think it's best to treat all user data as sensitive, and secure it in any way we can.

jonrnh

FYI, the latest update (4.6.2.624) to 1password v4 on Windows 10 uses "native messaging" by default. That appears to require this line in the sandboxie.ini for the Chrome extension to work (or you can set 1password use Websocket protocol in the actual program Help/Advanced/Use WebSocket Protocol).

OpenPipePath=\device\namedpipe\1password4.1

I haven't bother to figure out if any of the other opening lines can be removed.

AGAlumB

Thanks for sharing that! Just to clarify, Native Messaging is disabled by default in 1Password 4; Web Sockets is still the default since we don't want this to interfere with 1Password 6 in cases where someone is using both still. Cheers! :)

SergeyTheAgile

@jonrnh thanks for the sandboxie configuration tip, in case you use 1Password 6 that line would be OpenPipePath=\device\namedpipe\1password.1. Also, in both cases last 1 is actually your user session id, which is 1 for most people in the world. But when you have multiple users - they will get different session id. Hope that helps :)

jonrnh

@brenty are you sure Native Messaging isn't the new default from Chrome on Windows 10? When my 1passwd4 updated that was turned on (otherwise I wouldn't have noticed the problem). Also see https://blog.agilebits.com/2017/07/19/introducing-native-messaging-for-the-1password-extension/, which says " If you’re using a supported browser, 1Password will switch to native messaging immediately."

@SergeyTheAgile that's for that info. I am using 1passwd4 (don't like subscriptions).

Frustratingly nativemessaging is not working now. 1passwd4 hasn't updated. Not sure what's going on. I've gone back to WebSockets for now.

MikeT

Hi @jonrnh,

You are correct, 1Password 4 and 6 has Native Messaging enabled by default now. The original plan was to not do it by default in 1Password 4 but we've changed it at last minute because we were able to get 1Password 4 to not disable 1Password 6's Native messaging support if it is installed.

To be clear, 1Password 4 will not override 1Password 6's native messaging support if it is installed but if it is not, it will have it enabled.

Frustratingly nativemessaging is not working now. 1passwd4 hasn't updated. Not sure what's going on. I've gone back to WebSockets for now.

To be clear, it doesn't work in Sandboxie only or outside of Sandboxie as well?

jonrnh

The latest 1password4 release seems to have fixed the problems I had been seeing (i.e. the OpenPipePath is now working consistently).

AGAlumB

Thanks for the update! Glad to hear it's working better for you now. :)

Canukey

Not having any luck with Sandboxie anymore now that I've installed the latest Firefox extension update enabling native messaging. Could somebody post their Sandboxie configuration if they have this working?

Thanks!

AGAlumB

@Canukey: First and foremost, keep in mind that Sandboxie is not supported by 1Password, nor 1Password supported by Sandboxie, so your mileage may vary.

With the changes to 1Password to support Native Messaging in Firefox (and Chrome), most of this discussion no longer applies. Instead, you should be able to get it working by having the following processes running in the same sandbox:

• C:\Program Files (x86)\1Password 4\1Password.exe
• C:\Program Files (x86)\1Password 4\Agile1pAgent.exe
• C:\Program Files (x86)\1Password 4\1Password.NativeMessagingHost.exe
• C:\Program Files\Mozilla Firefox\Firefox.exe

That way these 1Password and Firefox processes can all communicate with each other. With the introduction of Native Messaging, mutual authentication is no longer needed, and therefore access to C:\Users\(user name)\AppData\Local\AgileBits\OPX4.auth is no longer relevant. You may need to make some tweaks to allow for access to data outside the sandbox if you want to be able to make changes (and have them be saved), but this will get things working as far as browser integration. Cheers! :)