Do 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.
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.