4 ms·
The problem I see is that their Linux Keying integration is as far as I can tell done in a way it's not supposed to be used by anything and as such they need to
by dathinab 5y ago
The problem I see is that their Linux Keying integration is as far as I can tell done in a way it's not supposed to be used by anything and as such they need to ship with a SUID binary helper, basically a (hopefully) harmless root backdoor.
(And I'm not speaking about the chrome/electrone sandbox, which can be run without SUID on modern systems).
- ag_christian 5y agoDo you mind expanding on why its problematic? We've built the kernel keyring integrations primarily to power the browser integration feature. In this case, "anything" ranges from users curious how it works to malware looking to steal credentials. 1Password puts in effort where possible to defend against attacks on your local system, so we need the keys currently used as part of the kernel keyring integration to be inaccessible to anything in userspace or otherwise some malware could steal credentials going back/forth to the browser. The SUID binary helper is unfortunate, but you can blame Linux for that. Our integration makes extensive use of the KEYCTL_CHOWN and KEYCTL_SETPERM syscalls for the reasons stated above, but a process needs the `CAP_SYS_ADMIN` capability to call them (ctrl+f on the man page for capabilities). In the end, we decided that making it SUID was more transparent to users then giving it that capability on install since the former is more visible.