linux-kernel - FUSE proxying for ABI filesystems?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <550DB35E.7090801@gmail.com>
Date:	Sat, 21 Mar 2015 18:07:26 +0000
From:	Topi Miettinen <toiwoton@...il.com>
To:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/