Date: Tue, 9 Jul 2019 13:58:37 +0000 From: Malte Kraus <malte.kraus@...e.com> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com> Subject: Privileged File Access from Desktop Applications With Wayland, it's no longer supported to run graphical applications as root. The big desktop environments want to allow users to edit and manage files through graphical applications (mostly text editors and file managers). They have therefore implemented D-Bus services to perform file I/O as root, authenticated through polkit. We have reviewed various of these: a) a specialized D-Bus service for ktexteditor, the framework component powering the Kate editor b) gvfs-admin, which allows all gtk-enabled applications to access files as root c) the kauth helper for ioslave, which allows KDE applications to access files as root As privileged file I/O is notoriously hard to get right, we found some concrete security issues in them  , which the projects were glad to fix. However, we believe there also some deeper design design choices that also merit further discussion. None of the solutions actually provided the user with the accessed path or file operation in the polkit auth prompt. Users are confronted with an unspecific request for privileges that they can only allow or deny without knowing what exactly they are allowing. (This is unfortunately a common theme, e.g. on KDE the framework is still missing support for parameterizing polkit prompts.) There's also a conceptual risk with the generic backends for file I/O: unwitting applications that were written expecting to be run from an unprivileged context can end up performing privileged file I/O operations when supplied with such a URI/path. As a result, even when the framework correctly implements all API guarantees for these backends, applications are likely to be too careless with their framework calls, resulting in situations where e.g. symlink attacks can be performed. Of course due to the authentication requirements, user interaction is involved in any such situation. Another matter with gvfs-admin for example is what the desired behaviour is when files are copied or moved between the 'normal' file system and the virtual privileged file system - these operations are no longer symmetric like they are traditionally: A rename(2) call is either performed as root or not. But with a move of a file from file:// (unprivileged) to admin:// (privileged), there are two different privilege levels involved. Since there is no equivalent to this situation in the UNIX file system semantics, it is unclear who should own the resulting file and what permissions it should have. Should file ownership be preserved? Should the file be owned by root? If an existing file is replaced, maybe the ownership and permissions of that file should be preserved? How does a setgid bit on a directory affect all this? What about higher-level flags in the framework like G_FILE_COPY_ALL_METADATA and G_FILE_COPY_TARGET_DEFAULT_PERMS? It's all quite underspecified, and we have the impression these questions weren't fully thought through before the feature shipped. Similar questions arise with the two KDE solutions, and some of the bugs probably arose exactly because these questions are not answered yet. Best regards Malte Kraus, Matthias Gerstner  CVE-2018-10361 https://seclists.org/oss-sec/2018/q2/65  CVE-2019-12447, CVE-2019-12448, CVE-2019-12449 -- Malte Kraus <malte.kraus@...e.com> Security Engineer PGP Key: 8AFC 3C58 6880 2DDD 4792 C3C2 FDBD 2984 D4C3 C2F0 SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.