7 ms·

I don't see what the difference is in security architecture between a desktop app and a web app implementing the same scheme? My assumption is that you've got

I don't see what the difference is in security architecture between a desktop app and a web app implementing the same scheme? My assumption is that you've got an E2EE link between the Signal app on the phone and the desktop app (with the messages decrypted on your phone in the middle). Why can't you do exactly the same thing with a web app?

nicce 5y ago
> I don't see what the difference is in security architecture between a desktop app and a web app implementing the same scheme? I just gave an example - execution environment is accessible by browser extensions. All the code and runtime data is visible for them with certain permissions.
- boring_twenties 5y ago
  How is that different from the desktop app? All the code and runtime data is visible to anyone running under the same uid, or the superuser.
  - nicce 5y ago
    No, they aren’t visible by default. Kernel isolates the memory space for every process. One of the basic fundamental things. Browser extensions can additionally modify code on the fly. On desktops it is really difficult since you need to inject code into memory. You are doing something wrong if you run your app as superuser or grant too much permissions by default.
    - boring_twenties 5y ago
      That is false, you can read the raw memory for any other process running under your uid. /proc/<PID>/mem You can also ptrace the process and completely control its execution.
      - nicce 5y ago
        Reading /proc/<PID>/mem requires access mode PTRACE_MODE_ATTACH_FSCREDS which is fundamentally same as access by using ptrace. Thus, kernel is indeed isolating process memory by default. It is true, that often you get PTRACE_MODE_ATTACH_FSCREDS with same UID/GId, but the most production systems have disabled ptrace or there are extra AppArmor rules to prevent its use. In most of the cases it is recommended to be disabled. For example latest Ubuntu allows only ptracing child processes on the same userspace (https://wiki.ubuntu.com/Security/Features#ptrace https://wiki.ubuntu.com/Security/Features#ptrace) You can also set your apps in such a way that they can’t be ptraced, for example ssh-agent is doing this with PR_SET_DUMPABLE attribute.
        boring_twenties 5y ago
        Thanks for the details. I didn't know Ubuntu was restricting ptrace by default now. Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently. Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file.
        nicce 5y ago
        > Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently. You could try to set it similarly than Ubuntu is doing. See Yama kernel module [1], and set mode 1 (restricted). > Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file. AppArmor[2] is useful for this, you could define profile for the untrusted app, and it cannot access any other file than you allow. [1]: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.... [2]: https://www.kernel.org/doc/html/latest/admin-guide/LSM/apparmor.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/appar...

nicce 5y ago

> I don't see what the difference is in security architecture between a desktop app and a web app implementing the same scheme? I just gave an example - execution environment is accessible by browser extensions. All the code and runtime data is visible for them with certain permissions.

boring_twenties 5y ago
How is that different from the desktop app? All the code and runtime data is visible to anyone running under the same uid, or the superuser.
- nicce 5y ago
  No, they aren’t visible by default. Kernel isolates the memory space for every process. One of the basic fundamental things. Browser extensions can additionally modify code on the fly. On desktops it is really difficult since you need to inject code into memory. You are doing something wrong if you run your app as superuser or grant too much permissions by default.
  - boring_twenties 5y ago
    That is false, you can read the raw memory for any other process running under your uid. /proc/<PID>/mem You can also ptrace the process and completely control its execution.
    - nicce 5y ago
      Reading /proc/<PID>/mem requires access mode PTRACE_MODE_ATTACH_FSCREDS which is fundamentally same as access by using ptrace. Thus, kernel is indeed isolating process memory by default. It is true, that often you get PTRACE_MODE_ATTACH_FSCREDS with same UID/GId, but the most production systems have disabled ptrace or there are extra AppArmor rules to prevent its use. In most of the cases it is recommended to be disabled. For example latest Ubuntu allows only ptracing child processes on the same userspace (https://wiki.ubuntu.com/Security/Features#ptrace https://wiki.ubuntu.com/Security/Features#ptrace) You can also set your apps in such a way that they can’t be ptraced, for example ssh-agent is doing this with PR_SET_DUMPABLE attribute.
      - boring_twenties 5y ago
        Thanks for the details. I didn't know Ubuntu was restricting ptrace by default now. Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently. Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file.
        nicce 5y ago
        > Now I need to figure out how to do that on my Debian system -- it definitely allows me to gdb attach to an unrelated process presently. You could try to set it similarly than Ubuntu is doing. See Yama kernel module [1], and set mode 1 (restricted). > Even that protection doesn't seem to make it safe to run untrusted programs under the same UID, though? If nothing else, there's always the classic "modify user's rc files to put my malicious program first in $PATH." Similarly you could modify them to increase the core file size rlimit, then send SIGSEGV to the process later and collect the core file. AppArmor[2] is useful for this, you could define profile for the untrusted app, and it cannot access any other file than you allow. [1]: https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.... [2]: https://www.kernel.org/doc/html/latest/admin-guide/LSM/apparmor.html https://www.kernel.org/doc/html/latest/admin-guide/LSM/appar...