I think the idea that HFS+ is not used on removable device is a bit of a
fallacy. I, myself, use this frequently on removable hard drives when moving
large data sets back and forth from my Mac. The Mac doesn't easily read ext
filesystems, but Linux can read HFS, and the various Microsoft
On Jan 10, Michael Biebl wrote:
> While we could ship such a udev rule for udisks, I don't think it will
> properly solve the issue. The device will still show up in nautilus, plasma
> etc and mounting is just an additional click away.
The threat model here is: somebody connects a crafted USB
On Sun, 27 Aug 2023 02:34:04 +0200 Marco d'Itri wrote:
So I propose this content for a file like
/usr/lib/udev/rules.d/75-insecure-fs.rules:
While we could ship such a udev rule for udisks, I don't think it will
properly solve the issue. The device will still show up in nautilus,
plasma
On Sat, 2023-07-22 at 12:11 +, Jeremy Stanley wrote:
> When the user has plugged in something that they don't realize
> contains a USB storage device, perhaps because it's attached to an
> internal hub within a device which has other purposes.
Probably it would be a good idea for Debian
On Sat, 2023-07-22 at 08:54 +0100, Matthew Garrett wrote:
> When is a user going to plug in a USB stick and *not* click that button?
When they found a USB stick in the parking lot, plugged it in, got the
error dialog & only then remembered their company security training :)
--
bye,
pabs
On Fri, 2023-07-21 at 18:35 +0100, Matthew Garrett wrote:
> On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
>
> > Unless somebody has a better idea then then my plan is to ship in the
> > next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> > directive to
On 2023-07-22 08:54:59 +0100 (+0100), Matthew Garrett wrote:
[...]
> 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
On Sat, Jul 22, 2023 at 10:21:47AM +0200, Jonas Smedegaard wrote:
> Quoting Matthew Garrett (2023-07-22 09:54:59)
> > On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote:
> > > Disabling auto-mounting and for manual GUI mounts, requesting users
> > > confirm they trust the filesystem they
Quoting Matthew Garrett (2023-07-22 09:54:59)
> On Sat, Jul 22, 2023 at 03:41:58PM +0800, Paul Wise wrote:
> > 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
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
On Fri, 2023-07-21 at 10:28 +, Bastien Roucariès wrote:
> Long term solution will be to push under fuse these filesystem.
> This a (short term)/(medium term band aid) solution.
That still potentially exposes insecure code to untrusted data, just in
a user context rather than a kernel
On Fri, Jul 21, 2023 at 09:49:48AM +, Bastien Roucariès wrote:
> I vaguely remember that someone implement a fuse over uml (user space linux)
A similar tool is libguestfs's guestmount tool:
On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> Unless somebody has a better idea then then my plan is to ship in the
> next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist
> directive to prevent automatically loading some file system modules.
I think this
Le vendredi 21 juillet 2023, 10:28:00 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> > On Jul 21, Bastien Roucariès wrote:
> >
> > > Ok found it call mountlo outdated
> > > will need a small patch for linux uml, but may be worthwhile
> > >
Le vendredi 21 juillet 2023, 10:52:17 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> > efs
> https://pypi.org/project/qnxmount/ claim to mount it. Check
> > hfs
> https://github.com/0x09/hfsfuse
Corrected not supported by this package may be
Le vendredi 21 juillet 2023, 08:55:39 UTC Marco d'Itri a écrit :
> efs
https://pypi.org/project/qnxmount/ claim to mount it. Check
> hfs
https://github.com/0x09/hfsfuse
> hfaplus
https://github.com/0x09/hfsfuse
> qnx6
Fuse ro filesystem https://pypi.org/project/qnxmount/ better support then
Le vendredi 21 juillet 2023, 10:17:13 UTC Marco d'Itri a écrit :
> On Jul 21, Bastien Roucariès wrote:
>
> > Ok found it call mountlo outdated
> > will need a small patch for linux uml, but may be worthwhile
> > Last version seems to be outdated 0.6 and carried by slitaz distribution.
> > May
Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
> Hi
> > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > > Package: src:linux
> > > Severity: normal
> > >
> > > You are totally correct.
>
On Jul 21, Bastien Roucariès wrote:
> Ok found it call mountlo outdated
> will need a small patch for linux uml, but may be worthwhile
> Last version seems to be outdated 0.6 and carried by slitaz distribution.
> May be time to revive it
It looks like a good long term solution, but as long as
Le vendredi 21 juillet 2023, 09:49:48 UTC Bastien Roucariès a écrit :
> Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
> Hi
> > On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > > Package: src:linux
> > > Severity: normal
> > >
> > > You are totally correct.
>
Hi Marco, hi,
Marco d'Itri - 21.07.23, 10:55:39 CEST:
> On Jul 21, Matthew Garrett wrote:
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> >
> > Isn't this a userland policy decision? udisks will happily trigger a
> > module load for hfsplus if
Le vendredi 21 juillet 2023, 08:20:12 UTC Matthew Garrett a écrit :
Hi
> On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> > Package: src:linux
> > Severity: normal
> >
> > You are totally correct.
> > Kernel team, please blacklist HFS/HFS+ for automounting.
>
> Isn't this a
If an official procedure to disable the driver completely is documented
and hosted from an official debian server it would be, in my opinion,
an acceptable solution.
Users would have a copy-pastable procedure to disable HFS if the risk
is intolerable to them, sysadmin would have an official page
Looks reasonable.
Le vendredi 21 juillet 2023 à 10:55 +0200, Marco d'Itri a écrit :
> On Jul 21, Matthew Garrett wrote:
>
> > > You are totally correct.
> > > Kernel team, please blacklist HFS/HFS+ for automounting.
> >
> > Isn't this a userland policy decision? udisks will happily trigger
> >
On Jul 21, Matthew Garrett wrote:
> > You are totally correct.
> > Kernel team, please blacklist HFS/HFS+ for automounting.
> Isn't this a userland policy decision? udisks will happily trigger a
> module load for hfsplus if udev has identified it, and I don't think
> there's a trivial
On Thu, Jul 20, 2023 at 07:56:12PM +0200, Marco d'Itri wrote:
> Package: src:linux
> Severity: normal
>
> You are totally correct.
> Kernel team, please blacklist HFS/HFS+ for automounting.
Isn't this a userland policy decision? udisks will happily trigger a
module load for hfsplus if udev has
26 matches
Mail list logo
