[systemd-devel] [PATCH/RFC] FuseMAC: user space MAC in systemd

[Topi Miettinen]

On 03/08/15 23:16, Lennart Poettering wrote:
> On Mon, 02.03.15 22:49, Topi Miettinen (toiwoton at gmail.com) wrote:
> 
>> Intercept and filter filesystem operations of processes launched
>> by systemd with FUSE.
>>
>> Implement learning, enforcing and auto enforcing/learning modes,
>> enabled with new exec directive FuseMAC.
>>
>> 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.
>>
>> Due to limitations of FUSE, API file systems can't be intercepted.
>>
>> Also the patch seems to trigger bugs in kernel (hang CPU).
> 
> Hmm, if I understand this patch right, then you proxy all file system
> access through a userspace fuse tool to enforce additional access
> restrictions?

All except file systems like /dev, /proc, /sys etc.

> Well, I am pretty sure that systemd should not be in the business of
> implementing a new access control mechanism. It's fine to expose ones
> that are supported in the kernel in ways, or even using things like
> namespacing to implement access control, but it really shouldn't be
> systemd that is the one enforcing file access rights here, I am very
> sure. It might be the place to encode and configure policy, but not
> the place to enforce it.

OK. It may be better design to keep it separate anyway, for example library.

> I think this is better done outside of systemd, and quite frankly, in
> the kernel, already for performance reasons.

Some of the access control is already performed by kernel (due to flag
default_permissions), I'm only adding on top of that. Performance isn't
so bad either.

Not doing the access control in kernel is actually the strength here. I
don't think it would be reasonable to expect kernel to support fine
grained byte range type of access control or automatic mode. From user
space it's possible to perform very complex checks, involve external
state and even query the user.

For example, one of the nice ideas in TOMOYO Linux is the ability to
base rules on the ancestry of a process, like "<kernel> /sbin/init
/usr/bin/dbus-daemon" is different from "<kernel> /sbin/init
/usr/bin/kdm /usr/bin/dbus-daemon". This would be pretty easy to
implement to FuseMAC. I'm not sure this would be possible with SELinux
and it's a weakness in AppArmor.

Byte ranges let FuseMAC differentiate between, for example, 'bash -c
exit' and 'bash -c "echo foo;exit', which is far beyond what any current
MAC can do.

The kernel could be a bit more helpful, now it's not possible to know if
reading a file happens due to mmap() or read(). Maybe this information
could be delivered by FUSE as well, or we could ptrace() the process.
Then FuseMAC would match AppArmor's 'm' (mmap) flag.

> Sorry!

NP.

-Topi

> Lennart
>