Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #108714
| From | Matthew Garrett <mjg59@srcf.ucam.org> |
|---|---|
| Newsgroups | linux.debian.devel |
| Subject | Re: HFS/HFS+ are insecure |
| Date | 2023-07-22 10:00 +0200 |
| Message-ID | <GUfGW-1Vd5-11@gated-at.bofh.it> (permalink) |
| References | <GTG6t-1z5m-7@gated-at.bofh.it> <GTVoR-1ICx-1@gated-at.bofh.it> <GTVoS-1ICx-7@gated-at.bofh.it> <GTVyx-1IFz-15@gated-at.bofh.it> <GUfxf-1V9t-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote: > That still potentially exposes insecure code to untrusted data, just in > a user context rather than a kernel context. The same goes for uml + > fuse + namespaces, and even guestfs VMs. You can move the data and code > to different contexts, but that doesn't change the fundamental issue. That's still a huge win! You can seccomp it, you can assign LSM restrictions, you can significantly reduce the risk associated with mounting an untrusted filesystem. We have many more controls in a user context than we do in a kernel context. > Disabling auto-mounting and for manual GUI mounts, requesting users > confirm they trust the filesystem they are mounting would avoid that as > much as is reasonably possible without entirely deleting the code and > without breaking the use-cases of people who need the filesystem code. When is a user going to plug in a USB stick and *not* click that button? I'm not analysing a filesystem by hand to check whether it's trustworthy before I want it mounted. There's no reason to automount when the screen is locked and presenting a dialog in the case where one was plugged in and then the screen unlocked is reasonable, but that just makes no sense as generic behaviour.
Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bug#1041552: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-20 20:10 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 10:30 +0200
Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 11:00 +0200
Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:10 +0200
Re: HFS/HFS+ are insecure Martin Steigerwald <martin@lichtvoll.de> - 2023-07-21 12:10 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:00 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-21 19:40 +0200
Re: HFS/HFS+ are insecure Ben Hutchings <ben@decadent.org.uk> - 2023-07-23 02:40 +0200
Re: HFS/HFS+ are insecure Magissia <debianlist@magissia.com> - 2023-07-21 11:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:00 +0200
Re: HFS/HFS+ are insecure Marco d'Itri <md@Linux.IT> - 2023-07-21 12:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:30 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 13:10 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-22 09:50 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:00 +0200
Re: HFS/HFS+ are insecure Jonas Smedegaard <jonas@jones.dk> - 2023-07-22 10:30 +0200
Re: HFS/HFS+ are insecure Matthew Garrett <mjg59@srcf.ucam.org> - 2023-07-22 10:40 +0200
Re: HFS/HFS+ are insecure Jeremy Stanley <fungi@yuggoth.org> - 2023-07-22 14:50 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:40 +0200
Re: HFS/HFS+ are insecure Paul Wise <pabs@debian.org> - 2023-07-25 06:30 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <rouca@debian.org> - 2023-07-21 12:20 +0200
Re: HFS/HFS+ are insecure Bastien Roucariès <bastien.roucaries@cyu.fr> - 2023-07-21 12:30 +0200
Re: HFS/HFS+ are insecure Seth Arnold <seth.arnold@canonical.com> - 2023-07-21 23:20 +0200
csiph-web