FUSE proxying for ABI filesystems?

[Topi Miettinen <toiwoton@gmail.com>]

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