Bug 1662193
Summary: | [RFE] Read-Only lockdown for removable drives | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Paul Gozart <pgozart> |
Component: | gvfs | Assignee: | Ondrej Holy <oholy> |
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.1 | CC: | amike, bnocera, jeischma, jkoten, pgozart, tpelka |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | 8.1 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | gvfs-1.36.2-4.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-11-05 22:13:35 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1709937 | ||
Bug Blocks: |
Description
Paul Gozart
2018-12-26 23:39:10 UTC
(In reply to Paul Gozart from comment #0) > Description of problem: > By default, an Android device using the MTP/PTP protocol is set to > read/write mode on RHEL7. We would like to prevent our users of writing > data to such a device, this means we need these devices to be mounted > read-only. Please create a setting or parameter that forces read-only mode > for MTP devices. What level of security/read-onlyness do you expect here? To be able to access files on MTP devices, the user is given read/write access to a USB device node. The write access is necessary to send commands to the device, such as "list all your files". Making the device node read-only would prevent it from being accessed, rather than making it read-only. Making the filesystem read-only would require changes in the gvfs MTP filesystem, but those would only be respected by gvfs (the backend used by Files, GNOME's file manager), and other applications (both graphical and command-line applications) that use libmtp directly would not respect it unless also modified. > Version-Release number of selected component (if applicable): > RHEL 7.6 > > > How reproducible: > Repeatedly > > > Steps to Reproduce: > 1. Attach Android/iPhone device to RHEL 7.6 Workstation via USB iPhones don't use MTP, though similar comments to above apply. > 2. Observe files can be read and written from/to such devices > > > Actual results: > RW is enabled to attached devices > > > Expected results: > Desired results would be setting that allows only read, not write (In reply to Bastien Nocera from comment #3) > (In reply to Paul Gozart from comment #0) > > Description of problem: > > By default, an Android device using the MTP/PTP protocol is set to > > read/write mode on RHEL7. We would like to prevent our users of writing > > data to such a device, this means we need these devices to be mounted > > read-only. Please create a setting or parameter that forces read-only mode > > for MTP devices. > > What level of security/read-onlyness do you expect here? To be able to access > files on MTP devices, the user is given read/write access to a USB device > node. > The write access is necessary to send commands to the device, such as "list > all > your files". Making the device node read-only would prevent it from being > accessed, > rather than making it read-only. > > Making the filesystem read-only would require changes in the gvfs MTP > filesystem, > but those would only be respected by gvfs (the backend used by Files, > GNOME's file > manager), and other applications (both graphical and command-line > applications) > that use libmtp directly would not respect it unless also modified. The customer is wanting the following (in order of importance): 1. The ability to configure a workstation to not allow data to be copied to a USB-attached Android or iOS device. 2. If possible, additional flexibility to configure the workstation to allow reads only from the device. Currently, the customer can attach his Android device to his RHEL Workstation and copy data via MTP to the device which is obviously a security concern they want to address. First and foremost, they want to keep data from leaving their environment on cell phones, etc. > > > Version-Release number of selected component (if applicable): > > RHEL 7.6 > > > > > > How reproducible: > > Repeatedly > > > > > > Steps to Reproduce: > > 1. Attach Android/iPhone device to RHEL 7.6 Workstation via USB > > iPhones don't use MTP, though similar comments to above apply. Yes, the main tester at my customer has an Android so that is what he tested with but they are concerned about all devices. > > > 2. Observe files can be read and written from/to such devices > > > > > > Actual results: > > RW is enabled to attached devices > > > > > > Expected results: > > Desired results would be setting that allows only read, not write (In reply to Paul Gozart from comment #4) > The customer is wanting the following (in order of importance): > > 1. The ability to configure a workstation to not allow data to be copied to > a USB-attached Android or iOS device. > 2. If possible, additional flexibility to configure the workstation to allow > reads only from the device. > > Currently, the customer can attach his Android device to his RHEL > Workstation and copy data via MTP to the device which is obviously a > security concern they want to address. First and foremost, they want to > keep data from leaving their environment on cell phones, etc. What's the current lockdown of those machines? Do users have root access? Are users allowed to install packages? Do users have access to a terminal? Will a compiler be installed on those machines? Are the end-user devices kiosks? Note that anything we might do for MTP, or PTP, or iOS devices still wouldn't have an impact on devices that appear as mass storage devices (cameras, e-book readers, etc.). I'd just like to mention as early as possible that this "security" is no security at all. The devices are still accessible by the users, so they can work-around that lockdown in a lot of different ways. As long as it's understood that it's security through obscurity and could be circumvented in a number of different ways, with and without root access, then that's fine. Otherwise, the only way to fix this properly is to remove libmtp and whatever depends on it, so that the device nodes aren't tagged as user-accessible through udev rules. In any case, I don't think that's something that upstream libmtp will want, as that's policy, and libmtp is a hardware access library, and isn't in a position to apply policy. Adding a "open as read-only" feature in libmtp would also require new API, and an ABI breakage to add more information about file/directory permissions. The way I would implement this (with the caveat that it's incomplete, and not actually impossible to work-around) is: - add lockdown setting to gsettings-desktop-schemas to mount to removable filesystem mounts as read-only - add code in gvfs to respect this setting for the afc, gphoto2, and mtp backends - add code in gvfs's udisks monitor to mount removable media as read-only (might also need udisks changes?) Ondrej, I'll reassign this to you to implement. Let me know if you think that's all implementable as far as gvfs is concerned, and I can look into the gsettings-desktop-schemas changes if needed. Finally, the solution based on Comment 8 has been implemented. The "mount-removable-storage-devices-as-read-only" key has been added in "org.gnome.desktop.lockdown" settings provided by gsettings-desktop-schemas. If enabled, it prevents users from writing or modifying files on removable storage devices (i.e. flash disks, mobile phones, cameras) in GNOME. Just note that mounts made manually over gnome-disk-utility, or some non-GNOME software, can still bypass this lockdown setting. To limit those cases, I would recommend using this setting together with a custom udev rule, which enforces read-only mounts of removable storage devices. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:3553 |