From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751637AbbCUSHb (ORCPT ); Sat, 21 Mar 2015 14:07:31 -0400 Received: from mail-we0-f179.google.com ([74.125.82.179]:33425 "EHLO mail-we0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751470AbbCUSH3 (ORCPT ); Sat, 21 Mar 2015 14:07:29 -0400 Message-ID: <550DB35E.7090801@gmail.com> Date: Sat, 21 Mar 2015 18:07:26 +0000 From: Topi Miettinen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, fuse-devel@lists.sourceforge.net Subject: FUSE proxying for ABI filesystems? OpenPGP: id=D610E936 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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