Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.devel > #108723

Re: HFS/HFS+ are insecure

From Ben Hutchings <ben@decadent.org.uk>
Newsgroups linux.debian.devel, linux.debian.kernel, linux.debian.bugs.dist
Subject Re: HFS/HFS+ are insecure
Date 2023-07-23 02:40 +0200
Message-ID <GUviF-259b-1@gated-at.bofh.it> (permalink)
References (6 earlier) <GTG6t-1z5m-23@gated-at.bofh.it> <GTG6t-1z5m-31@gated-at.bofh.it> <GTTGp-1HxK-3@gated-at.bofh.it> <GTU9r-1HIa-5@gated-at.bofh.it> <GU2gH-1MGS-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 3 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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 prevent automatically loading some file system modules.
> 
> I think this would break any existing fstab entries that reference hfs 
> and hfsplus, and the convenient way to integrate Linux boot with x86 
> Macs is certainly to have an hfsplus EFI partition so this may be a 
> legitimate use-case. It also means that anyone who has a need to use one 
> of these filesystems in a static manner is vulnerable to automount 
> attacks using them.

Right, auto-loading of filesystems has to keep working.  And since
mount() of arbitrary filesystems is restricted to root (CAP_NET_ADMIN
in the initial namespace), we should let the callers apply a block- or
allow-list.

The reason we have to disable auto-loading of network protocols is that
socket creation is generally an unprivileged operation, so there's no
trusted user-space that can apply the policy (besides kmod).

> Completely untested, but I think something along the lines of:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
> LABEL="udisks_insecure_fs_end"
> 
> in a udev fragment should work? Any static fstab or mount units should 
> still work, but it should disable udisks automounting regardless of the 
> desktop agent involved, even if the fs modules are already loaded.

I agree we should not have UDisks probing for any of the (many) kernel
filesystems that aren't being actively maintained including responding
to security issues.

Beyond that, I would also like to see libmount limiting the filesystems
that it will probe when the fstab type is "auto".  But since UDisks
normally handles mounting for unprivileged users, that's probably less
of a concern.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


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