Warum wird FUSE auf dem Server als unsicher angesehen?

336
Lapsio

OpenSUSE enthält mehrere vordefinierte Berechtigungseinstellungen. Paranoid ist sehr restriktiv. Ich verstehe zwar, warum es Dinge wie Virtualisierung oder tty-Broadcasts für Nicht-Root-Benutzer blockiert, ich verstehe jedoch nicht, warum es auch blockiert fuse. Gibt es ein echtes Sicherheitsproblem, das durch die Sicherung auf einem gemeinsam genutzten Server verursacht wird?

3
Hast du diese Webseite gesehen? http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/html/security.html MariusMatutiae vor 7 Jahren 3

1 Antwort auf die Frage

1
Kamil Maciorowski

This useful comment links to this Web page. Below is an extract from the page:

Security Concerns

Writing and using a FUSE filesystem can have some Metrodome-sized security concerns that may or may not be obvious, but deserve some mention. In this section, I'll be talking about privilege escalation, giving some notes on checking access rights, and mentioning race conditions.

Privilege Escalation

The main point to make is that the filesystem itself executes with the access privileges of the process running it, not those of the process making use of the filesystem. Here's how this plays out in some typical scenarios:

The Common Case: a User Runs the Filesystem Without the allow_other Option

This is the normal case; the filesystem runs with the privileges of the user that ran it, and only that user can access the filesystem. FUSE doesn't open up any particular security issues in this case.

A User Runs the Filesystem With the allow_other Option

In this case, the filesystem runs with the privileges of the user that invoked it, not the privileges of any user who happens to make use of the filesystem. It's the responsibility of the user who mounts the filesystem to ensure inappropriate access privileges aren't being granted to other users. In general, users can only hurt themselves this way, since they can only grant privileges that they themselves already have.

It should be noted that an option, user_allow_other, must be set in /etc/fuse.conf to enable this option.

Root Runs a Filesystem

This is really the same as the previous two cases (depending on whether the allow_other option is set), but root is a sufficiently special case that it deserves mention. In this case, any user making use of the filesystem has root privileges on that filesystem! If the process has access to the actual filesystem, this could easily be used to gain pretty much unlimited access.

The next subsection will talk a little bit about checking access rights, but the simplest way out here is to not allow root to mount the filesystem. […]

Checking Access Rights

In general, a filesystem that might be executed with the allow_other flag will need to take steps to ensure its own security. fuse.h documents that several calls need to check that the requested access is permitted; in addition to those, there are several others that also require access checks (such as chown()). It is strictly the programmer's responsibility to make sure these cautions are followed!

[…]

Simultaneous Access and Race Conditions

By default, FUSE runs multi-threaded: this means (in brief) that a second request can be handled by the filesystem before an earlier request has completed; this in turn raises the possibility that different threads can be simultaneously modifying a single data structure, which will cause very difficult-to-debug bugs.

[…]