Messages in this thread | | | Date | Sat, 21 Mar 2015 18:07:26 +0000 | From | Topi Miettinen <> | Subject | FUSE proxying for ABI filesystems? |
| |
Hello all,
I've made a small control program that intercepts and filters filesystem operations of processes launched by it with FUSE. With it, FS operations can be filtered by access type (e.g. getattr/read, cf. AppArmor or TOMOYO Linux) or for more fine grained control, which area of the file is being accessed. This lets me differentiate between, for example, 'bash -c exit' and 'bash -c "echo foo;exit"', which is far beyond what any current MAC can do. It works even with complex programs like iceweasel or chromium with only some slowdown on startup.
But due to limitations of FUSE, ABI file systems etc. (/proc, /sys, certain devices) can't be intercepted very well. For example, it's pretty easy (maybe racy) to change readlink("/proc/self") to readlink("/proc/$PID_OF_CLIENT"). But handling the client opening TTY devices _without_ O_NOCTTY does not look so simple and there seems to be a number of other interesting cases. For more fun, the control program and its client can be in different namespaces and maybe even the client should be able to perform arbitrary mounting and namespace operations, even use FUSE recursively.
I think how to manage this mess would be that it should be possible for the control program to switch temporarily its way of viewing and using ABI file systems in a way that setfsuid()/setfsgid() does not allow, but so that the above cases can be handled reliably.
For example, a new system calls could be added like setfspid(pid_t client_pid) for /proc/self and TTY handling, and maybe something like setfsns() for namespace control.
-Topi
| |