3 ms·

I mean, if you use 1Password on both linux and iOS, you now trust both the mobile and desktop teams at 1password. You trust two separate supply chains, one for

I mean, if you use 1Password on both linux and iOS, you now trust both the mobile and desktop teams at 1password. You trust two separate supply chains, one for the iOS app dependencies, one for the linux dependencies. If you use bitwarden, you now trust the "bitwarden/mobile" and the "bitwarden/clients" repositories. Both of those programs _also_ have separate applications with separate code for mobile and desktop, so for those you _also_ have to audit twice the code (well, not that you can audit 1password's code). Anyway, if you're using any of these programs on desktop, you have to trust 100% of the programs you run as the same user as your password store client to not be reading memory to nab your database, so it's not like trusting one more program is that big a deal. I'm not even sure if I'm being sarcastic or not.

ec109685 3y ago
Two programs running under same user can’t by default read each other’s memory.
- TheDong 3y ago
  > Two programs running under same user can’t by default read each other’s memory. 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user, and that sure lets me read all memory. I think /proc/$pid/mem works fine too, right? 'ReadProcessMemory' works fine as an unprivileged user on windows I _thought_, at least I know it did last time I used it. That was years ago. No clue about macOS. I assume most people on hacker news are using linux though, so that's the one that's relevant.
  - rootusrootus 3y ago
    > I assume most people on hacker news are using linux though, so that's the one that's relevant. I'd wager a beer that MacOS is the dominant OS. Followed by Windows. Followed by Linux.
  - natrys 3y ago
    > 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user I believe this requires `kernel.yama.ptrace_scope` to be set to 0, which is not the default in most distros? Or gdb to be granted specific capability, which I don't think is done by default either.
  - LittleShaman 3y ago
    On Linux you can prevent being ptrace'd or having your core dumped by setting PR_SET_DUMPABLE in prctl. I've seen this used in places you'd expect like ssh-agent and GNOME's Keyring password manager. Ctrl-f for 'PR_SET_DUMPABLE' in the manpages: - https://man7.org/linux/man-pages/man2/prctl.2.html https://man7.org/linux/man-pages/man2/prctl.2.html - https://man7.org/linux/man-pages/man2/ptrace.2.html https://man7.org/linux/man-pages/man2/ptrace.2.html
  - lxgr 3y ago
    What distribution is that on? At least Ubuntu has had ptrace capabilities restricted to superuser processes and descendants for many years now, as far as I can remember. /proc/$pid/mem access needs ptrace permissions as well and accordingly follows the same rules.
batmanthehorse 3y ago
That’s a stretch
o1y32 3y ago
That's just fearmongering. By that logic you can never use any closed source product. How would people trust an Outlook client won't leak your emails, or iOS/Android/Windows/MacOS isn't sharing your personal information and other communication?

ec109685 3y ago

Two programs running under same user can’t by default read each other’s memory.

TheDong 3y ago
> Two programs running under same user can’t by default read each other’s memory. 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user, and that sure lets me read all memory. I think /proc/$pid/mem works fine too, right? 'ReadProcessMemory' works fine as an unprivileged user on windows I _thought_, at least I know it did last time I used it. That was years ago. No clue about macOS. I assume most people on hacker news are using linux though, so that's the one that's relevant.
- rootusrootus 3y ago
  > I assume most people on hacker news are using linux though, so that's the one that's relevant. I'd wager a beer that MacOS is the dominant OS. Followed by Windows. Followed by Linux.
- natrys 3y ago
  > 'gdb -p $pid' works fine for me on linux as a non-root user for another pid of the same user I believe this requires `kernel.yama.ptrace_scope` to be set to 0, which is not the default in most distros? Or gdb to be granted specific capability, which I don't think is done by default either.
- LittleShaman 3y ago
  On Linux you can prevent being ptrace'd or having your core dumped by setting PR_SET_DUMPABLE in prctl. I've seen this used in places you'd expect like ssh-agent and GNOME's Keyring password manager. Ctrl-f for 'PR_SET_DUMPABLE' in the manpages: - https://man7.org/linux/man-pages/man2/prctl.2.html https://man7.org/linux/man-pages/man2/prctl.2.html - https://man7.org/linux/man-pages/man2/ptrace.2.html https://man7.org/linux/man-pages/man2/ptrace.2.html
- lxgr 3y ago
  What distribution is that on? At least Ubuntu has had ptrace capabilities restricted to superuser processes and descendants for many years now, as far as I can remember. /proc/$pid/mem access needs ptrace permissions as well and accordingly follows the same rules.

batmanthehorse 3y ago

That’s a stretch

o1y32 3y ago

That's just fearmongering. By that logic you can never use any closed source product. How would people trust an Outlook client won't leak your emails, or iOS/Android/Windows/MacOS isn't sharing your personal information and other communication?