profiles: blacklist i3 IPC socket & dir except for i3 itself #6361
Conversation
| @@ -167,6 +167,10 @@ blacklist ${RUNUSER}/gnome-session-leader-fifo | |||
| blacklist ${RUNUSER}/gnome-shell | |||
| blacklist ${RUNUSER}/gsconnect | |||
|
|
|||
| # i3 IPC socket (allows arbitrary shell script execution) | |||
| blacklist ${RUNUSER}/i3/ipc-socket.* | |||
| blacklist /tmp/i3-*/ipc-socket.* | |||
There was a problem hiding this comment.
Is there anything else in the i3 directory?
XY: Would it make sense to blacklist the directory?
There was a problem hiding this comment.
On my system, the only other files in there are an error log and another UNIX domain socket called log-stream-socket.*. Seems neither very dangerous nor very useful, so it probably doesn't matter either way.
There was a problem hiding this comment.
Logs could contain sensitive information.
If there is thing important in it we should blacklist the directory IMHO.
There was a problem hiding this comment.
FWIW, I agree. Targetting the directory is the better option here.
There was a problem hiding this comment.
Fair enough, I changed it to block the entire directories.
There was a problem hiding this comment.
Files that allow command execution are usually made read-only or blacklisted.
Unnecessary directories are usually blacklisted.
So why not both?
I think it would be helpful to have the actual socket paths documented and
having specific entries for them would be one way to do it.
I restored the socket paths, moved the directories to disable-programs.inc,
added the description to the commit message and force-pushed.
Thoughts?
kmk3
changed the title
smheidrich
force-pushed
the
blacklist-i3-ipc-socket
branch
from
b554df9
to
0af8540
Compare
This closes the escape route discussed in netblue30#6357. It's left open for i3's own profile, so that people who run i3 itself sandboxed still have the option to use IPC with it at all. Reference for file paths: https://i3wm.org/docs/userguide.html#_interprocess_communication
kmk3
force-pushed
the
blacklist-i3-ipc-socket
branch
from
0af8540
to
87317dd
Compare
kmk3
changed the title
Much like the i3 IPC socket (netblue30#6361), the sway IPC socket also allows arbitrary code execution via the `exec` subcommand. Access should only be permitted to sway itself by default.
Much like the i3 IPC socket (netblue30#6361), the sway IPC socket also allows arbitrary code execution via the `exec` subcommand. Access should only be permitted to sway itself by default. The location of the IPC socket is set in sway/ipc-server.c: https://github.com/swaywm/sway/blob/7e74a4914261cf32c45017521960adf7ff6dac8f/sway/ipc-server.c#L126
Much like the i3 IPC socket (#6361), the sway IPC socket also allows arbitrary code execution via the `exec` subcommand. Access should only be permitted to sway itself by default. The location of the IPC socket is set in sway/ipc-server.c: https://github.com/swaywm/sway/blob/7e74a4914261cf32c45017521960adf7ff6dac8f/sway/ipc-server.c#L126
This closes the escape route discussed in #6357.
It's left open for i3's own profile, so that people who run i3 itself sandboxed still have the option to use IPC with it at all.
Reference for file paths: https://i3wm.org/docs/userguide.html#_interprocess_communication