4 ms·

> If these programs want to spy on each other's memory contents, they already can. No, they cannot. As an unprivileged process, you cannot access other process

> If these programs want to spy on each other's memory contents, they already can. No, they cannot. As an unprivileged process, you cannot access other processes' memory, with major distributions' default settings, even if the two processes share the same UID. The only way to achieve that would be to modify some execution path (e.g. .bashrc) to launch an evil wrapper which runs the target process in a way that allows reading its memory.

AshamedCaptain 5y ago
Which distributions and which settings are you talking about? If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). And as for the second method, that's why I said same home directory. But there is a gazillion of ways. You can even meddle in practically all IPC done by any two processes of the same UID, e.g. attach to sysv or posix shm.
- CyberShadow 5y ago
  > Which distributions and which settings are you talking about? kernel.yama.ptrace_scope = 1 > If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). No, you can't. Try it. > And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). You can trace child processes, but not any other process.
  - AshamedCaptain 5y ago
    Which distribution enables this by default ? EDIT: Apparently Ubuntu, but not Debian, SuSE, Arch, etc. Well, TIL. > No, you can't. Try it. You definitely can, it's just that that as you said, gdb just can't attach to anything but a child process; making gdb only work with a process it spawned itself. Anyway, in addition to changing .profile, you still can do practically everything including modifying SHM segments, writing to pipes, sockets, etc. You could start closing feature by feature (e.g. remove /proc like Android), but for some reason it doesn't seem like the right approach.
    - deleted 5y ago
      [deleted]
    - CyberShadow 5y ago
      > but for some reason it doesn't seem like the right approach. The approach being used in containerization is namespaces. You can put new processes into a new IPC / user / PID / network / time / etc. namespace, which isolates them from the parent namespace. Once that's done and you can't mess with other processes via the filesystem / kernel, the remaining hole is servers with inadequate security models, such as X11.
      - AshamedCaptain 5y ago
        What I mean is that if you are going to put your processes as a different user anyway (or a different user namespace), trying to break all the features that allow a user to manage same UID processes is unnecessary.

AshamedCaptain 5y ago

Which distributions and which settings are you talking about? If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). And as for the second method, that's why I said same home directory. But there is a gazillion of ways. You can even meddle in practically all IPC done by any two processes of the same UID, e.g. attach to sysv or posix shm.

CyberShadow 5y ago
> Which distributions and which settings are you talking about? kernel.yama.ptrace_scope = 1 > If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb). No, you can't. Try it. > And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it). You can trace child processes, but not any other process.
- AshamedCaptain 5y ago
  Which distribution enables this by default ? EDIT: Apparently Ubuntu, but not Debian, SuSE, Arch, etc. Well, TIL. > No, you can't. Try it. You definitely can, it's just that that as you said, gdb just can't attach to anything but a child process; making gdb only work with a process it spawned itself. Anyway, in addition to changing .profile, you still can do practically everything including modifying SHM segments, writing to pipes, sockets, etc. You could start closing feature by feature (e.g. remove /proc like Android), but for some reason it doesn't seem like the right approach.
  - deleted 5y ago
    [deleted]
  - CyberShadow 5y ago
    > but for some reason it doesn't seem like the right approach. The approach being used in containerization is namespaces. You can put new processes into a new IPC / user / PID / network / time / etc. namespace, which isolates them from the parent namespace. Once that's done and you can't mess with other processes via the filesystem / kernel, the remaining hole is servers with inadequate security models, such as X11.
    - AshamedCaptain 5y ago
      What I mean is that if you are going to put your processes as a different user anyway (or a different user namespace), trying to break all the features that allow a user to manage same UID processes is unnecessary.