3 ms·

> However the way Wayland (or its broader ecosystem) "fixes" security is just stupid. Instead of using a fine grained whitelisting based permission system to gr

> However the way Wayland (or its broader ecosystem) "fixes" security is just stupid. Instead of using a fine grained whitelisting based permission system to grant different clients all the permissions they need to do their work Because you can't do that in Unix. You can't ensure that the process with PID 1234 is really executing /usr/bin/foo.

owl57 9y ago
Assuming other apps are sandboxed from /proc/1234, can't the shell just exec "/usr/bin/foo" and pass some file descriptors or secrets in environment variables?
- jcantero 9y ago
  How the wayland server and the shell are going to share (or agree to) that file descriptors or secrets in the first place? Or how can you ensure that the shell is not a rogue one?
  - owl57 9y ago
    > How the wayland server and the shell are going to share (or agree to) that file descriptors or secrets in the first place? I read that GNOME just implements both in the same program (and calls it "shell"). > Or how can you ensure that the shell is not a rogue one? I'm confused. Do you mean this kind of attack would become somewhat more probable or more dangerous if the original shell had some mechanism of allowing certain apps to pick colors?
    - jcantero 9y ago
      The reason that Wayland (or X11) protocol uses Unix sockets for communications is because there is not a hierarchical relationship between a client process and the server process (they can be even from different user "sessions"). Also, a client can be launched from anywhere, including a "shell" such as a /bin/bash interactive session.
alien_at_work 9y ago
You can with SELinux, which is on all the major distros now, no?
- jcantero 9y ago
  I haven't heard about that, can you please provide a link?
  - alien_at_work 9y ago
    A link to info about SELinux? It's a rather broad topic, you'll probably be better served to google for what ever aspect of it you're interested in but it's definitely in Redhat (even turned on by default [1]) and it's on Debian (not sure if it's on by default there). [1] https://access.redhat.com/solutions/3176 https://access.redhat.com/solutions/3176 <--- here they show how to turn it off because it's in enforcing mode by default.
    - jcantero 9y ago
      About how to use SELinux to ensure that a process with certain PID is running the intended executable and that it hasn't been tampered by the user (i.e. a rogue app running with user perms).
      - alien_at_work 9y ago
        Well, you'd need to read up on how SELinux works to understand that. Briefly, SELinux adds some new permissions to files, new contexts to users and so on, so what happens is you specify what a given context is allowed to do, to a very granular level. For example, if you take postfix, it's split up into lots of programs, so you could say that the "init" context is allowed to run the postfix startup script but none of the rest of it. The postfix startup script will convert into some "postfix startup" context which is allowed to start the various programs but nothing else. So there will be a a postfix process that allows incoming IP addresses and can send on a specific FIFO and nothing else. There is another program which can read from the FIFO, change certain files and nothing else. So, imagine if you break into the program that talks with the internet: all you can do at that point is talk with the internet and talk with the FIFO. You can't read any files, write anything, execute anything, etc. So that's kind of the idea of it. The above assumes an extremely tight SELinux configuration and no bugs in SELinux that would allow you to break out of your context. I've never seen a configuration as tight as described above but there did use to be a guy who had a Debian linux machine running on the internet where you could log in as root and try to break stuff. As far as I know, no one ever hacked that machine, starting out as root in a bash shell.

owl57 9y ago

Assuming other apps are sandboxed from /proc/1234, can't the shell just exec "/usr/bin/foo" and pass some file descriptors or secrets in environment variables?

jcantero 9y ago
How the wayland server and the shell are going to share (or agree to) that file descriptors or secrets in the first place? Or how can you ensure that the shell is not a rogue one?
- owl57 9y ago
  > How the wayland server and the shell are going to share (or agree to) that file descriptors or secrets in the first place? I read that GNOME just implements both in the same program (and calls it "shell"). > Or how can you ensure that the shell is not a rogue one? I'm confused. Do you mean this kind of attack would become somewhat more probable or more dangerous if the original shell had some mechanism of allowing certain apps to pick colors?
  - jcantero 9y ago
    The reason that Wayland (or X11) protocol uses Unix sockets for communications is because there is not a hierarchical relationship between a client process and the server process (they can be even from different user "sessions"). Also, a client can be launched from anywhere, including a "shell" such as a /bin/bash interactive session.

alien_at_work 9y ago

You can with SELinux, which is on all the major distros now, no?

jcantero 9y ago
I haven't heard about that, can you please provide a link?
- alien_at_work 9y ago
  A link to info about SELinux? It's a rather broad topic, you'll probably be better served to google for what ever aspect of it you're interested in but it's definitely in Redhat (even turned on by default [1]) and it's on Debian (not sure if it's on by default there). [1] https://access.redhat.com/solutions/3176 https://access.redhat.com/solutions/3176 <--- here they show how to turn it off because it's in enforcing mode by default.
  - jcantero 9y ago
    About how to use SELinux to ensure that a process with certain PID is running the intended executable and that it hasn't been tampered by the user (i.e. a rogue app running with user perms).
    - alien_at_work 9y ago
      Well, you'd need to read up on how SELinux works to understand that. Briefly, SELinux adds some new permissions to files, new contexts to users and so on, so what happens is you specify what a given context is allowed to do, to a very granular level. For example, if you take postfix, it's split up into lots of programs, so you could say that the "init" context is allowed to run the postfix startup script but none of the rest of it. The postfix startup script will convert into some "postfix startup" context which is allowed to start the various programs but nothing else. So there will be a a postfix process that allows incoming IP addresses and can send on a specific FIFO and nothing else. There is another program which can read from the FIFO, change certain files and nothing else. So, imagine if you break into the program that talks with the internet: all you can do at that point is talk with the internet and talk with the FIFO. You can't read any files, write anything, execute anything, etc. So that's kind of the idea of it. The above assumes an extremely tight SELinux configuration and no bugs in SELinux that would allow you to break out of your context. I've never seen a configuration as tight as described above but there did use to be a guy who had a Debian linux machine running on the internet where you could log in as root and try to break stuff. As far as I know, no one ever hacked that machine, starting out as root in a bash shell.