Re: HFS/HFS+ are insecure

[Paul Wise]

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 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.

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. 

Of course sandboxing the code for those who need it is good too, so
probably we need both, along with ways to disable the mitigations.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: HFS/HFS+ are insecure

[Matthew Garrett]

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.

Re: HFS/HFS+ are insecure

[Jonas Smedegaard]

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 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? 

When the user had plugged in a coworker's phone they were asked to please
charge.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: HFS/HFS+ are insecure

[Matthew Garrett]

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 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? 
> 
> When the user had plugged in a coworker's phone they were asked to please
> charge.

We're a long way down the social engineering chain there - I think that 
turns into a question of how many people are going to benefit from not 
automounting because of that case vs the number who benefit from the 
convenience under normal circumstances.

Bug#1041698: ITP: ruby-flores -- Fuzz, randomize, and stress your tests

[thegodtune]

Package: wnpp
Severity: wishlist
Owner: Ajayi Olatunji 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: ruby-flores

   Version : 0.0.8
   Upstream Author : Jordan Sissel

* URL : https://github.com/jordansissel/ruby-flores#readme
* License : Apache
   Programming Lang:Ruby
   Description : Fuzz, randomize, and stress your tests

 Add fuzzing, randomization, and stress to your tests.
 .
 This library is an exploration to build the tools to let you write
tests that find bugs.
 .
 In memory of Carlo Flores.

 This package is a build dependency for ruby-arr-pm, a package required
in gitlab 15.11.6

-- 
thegodtune 


signature.asc
Description: This is a digitally signed message part

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Martin-Éric Racine]

On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
 wrote:
>
> On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
>  wrote:
> >
> > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > >  wrote:
> > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > > > Greetings,
> > > > > >
> > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might 
> > > > > > be a
> > > > > > good time to re-visit Debian's choice of standard DHCP client 
> > > > > > shipping
> > > > > > with priority:important.
> > > > > >
> > > > > > I hereby propose bin:dhcpcd-base:
> > > > > >
> > > > > > 1) already supported by ifupdown.
> > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege 
> > > > > > separation.
> > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > > > configure both stacks.
> > > > > ...
> > > > >
> > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for
> > > > > the moment, and I'll make the relevant changes in ifupdown as soon as 
> > > > > I
> > > > > can. Josué, any thoughts?
> > > >
> > > > 1) As someone pointed out in the thread, the reason why
> > > > isc-dhcp-client had priority:important probably was to ensure that
> > > > debootstrap would pull it, since debootstrap ignores Recommends and
> > > > packages with a priority lower than standard.
> > > >
> > > > 2) However, as long as ifupdown explictly depends on a package, it can
> > > > also pull dependencies with a lower priority. Right now ifupdown
> > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead.
> > > >
> > > > 3) At that point, swapping the priority of isc-dhcp-client and
> > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both
> > > > could, in principle, be optional, just as long as ifupdown explicitly
> > > > Depends on a DHCP client, and the first alternative is a real package.
> > >
> > > I was about to bump dhcpcd-base as ifupdown dependency, but... if
> > > isc-client-dhcp is a Recommends, is because not all users want a dhcp
> > > client installed, where all the ipv4 is handled statically, and ipv6 is
> > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the
> > > next upgrade.
> > >
> > > So I'd prefer to go forward with the steps proposed by Simon, and
> > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends:
> > > Unless there is a strong objection, I'll file the override bug report.
> >
> > (sorry for taking so long to come back to this)
> >
> > For the moment, ifupdown is still installed by the debian-installer as
> > default network interfaces manager. And after sleeping over it, and
> > discussing with debian fellows, I would like to call for consensus to
> > rise Priority: Important to dhcpcd-base (as initially requested in
> > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client.
> >
> > This addresses two scenarios: keep some systems as small as possible
> > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp
> > client available after installing/bootstrapping.
> >
> > So I would like to retitle #1038882 back as originally reported. (Sorry
> > for going back and forth) Objections?
> >
> > The situation regarding the default network interfaces manager could
> > change, even in the short term. But that could be discussed in another
> > thread.
>
> No objection. Raising the priority of dhcpcd-base to important works for me.

Have we reached a conclusion? Are we moving ahead with this or not?

Martin-Éric

Re: HFS/HFS+ are insecure

[Jeremy Stanley]

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 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.

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.

I've read about unsuspecting users buying/borrowing USB chargers and
cables which contain malicious widgets designed to backdoor systems.
Maybe it's urban legend because I don't personally know anyone who's
said they've had machines compromised that way, and most probably
target Windows/iOS/Android anyway even if they are in circulation,
but since the majority of my portable computing devices charge over
USB these days I try to be conscious of it and never plug into the
"convenient" charging ports supplied in airports, airplanes, hotel
rooms, conference rooms... I just bring my own chargers with me.

Also, while the risks of hacked USB devices isn't limited to
exploiting filesystem drivers (backdoored keyboards apparently also
exist, for example), I tend to not configure hotplug automounting
more for preference of having direct control over the system's
behavior. I would much rather explicitly call the mount command and
be able to decide where in the file tree it gets added, on the rare
occasion that I do actually need to plug in a storage peripheral for
some reason. I get that I'm probably an exception, but there are
definitely users who simply find automounting behavior annoying,
beyond any potential security concerns.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Santiago Ruano Rincón]

El 10/07/23 a las 14:52, Helmut Grohne escribió:
> On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote:
> > On top of that, a minimal installation chroot doesn't need a
> > fully-featured dhcp client. As Simon said already, busybox is there
> > for any reason for a minimal one. For the rest - installer and whatnot
> > - the installer and tasklets should pull in the required stack as
> > needed.
> 
> I contend that currently a debootstrap includes a dhcp client and this
> is more of a migration from one dhcp implementation to another. Since
> dhcp is the most common way of configuring a network, supporting it in
> ifupdown by default also seems like a reasonable choice.
> 
> > So I think not only we should not bump the priority of dhcpd-base, but
> > we should also change ifupdown's down to optional.

I would like to just echo this:

> 
> I don't quite see consensus on this yet, but I already see significant
> interest in changing the default network configuration method. I hope
> that it is out of question that we'd demote the priority of the
> recommended dhcp client when demoting the priority of ifupdown. Demotion
> of ifupdown needs to come with a proposed replacement and/or with
> changes to the debian-installer. I do hope that we can get that
> discussion going and implemented before trixie. However, this is about
> changing the default dhcp client for use with debootstrap and moving the
> priority from one package to another seems like an incremental
> improvement that is not blocking the bigger goal of changing the default
> network configuration tool in any way.
> 
> I expect that dhcpcd will not be important in trixie, but for now that
> move makes sense to me, because it is as easily reverted as it is
> implemented. This is an instance of "The perfect is the enemy of the
> good."

[snip]

Could we just give a shorter step right now to make things move forward,
and let the discussion about the default network interfaces
configuration tool for later?

Thanks,

 -- S


signature.asc
Description: PGP signature

Bug#1041717: ITP: tailspin -- log file highlighter and a drop-in replacement for tail -f

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: tailspin
  Version : 1.0.0
  Upstream Contact: Ben Sadeh
* URL : https://github.com/bensadeh/tailspin
* License : Expat
  Programming Lang: Rust
  Description : log file highlighter and a drop-in replacement for tail -f

 tailspin is a command line tool
 for viewing (and `tail`-ing) log files.
 It highlights important keywords
 to make navigating log files easier.
 .
 tailspin is fast and easy to customize.
 It uses less under the hood
 to provide scrollback, search and filtering.

This package will be maintained in the collaborative debian section of
salsa, at 

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS77PcACgkQLHwxRsGg
ASHujg//aUX/vCS+1Y2spgtQ0YCGnYoboEUcT9oXvyVH9RfLErLn+bdCl9/YkETK
5CEJU4EkS6Sol6bbmO1niQt+VoEeBsOxee4PSmcpB1g5kFOJJyxi9yCui8PVrti1
+BsB1myBx8bkvFptDhgW3fnsrWsm8Yvslq8d16v4D1OgjM+a6M8jjsl8RZm0k2dT
F60MEsvG3dIv+oKcFt2c98wN6MphDXOuq1p7JyMv775XUd0iWz3LLuFHFs9EOazx
eRk1OcxM6dmptFpCAbCt8OHalYJ6YcFCU+/70XurDN90qs3JfhcVHCmACORuFTWE
RV1h1vEfNds18YjDOLzo2DjYesvsHbnAVfBOu4Bdivg4QdhXZmI6hkFbWhMooN6z
CB5lca9X8Wj0C/5vgczTw53bDPbpOLXLw4Vfgyrq/Q7wApL4+nCjLrmQj9e3dRDo
w/ImpMhzJRJAMI1gVicduPS7Pko344GOQMvSesnqYUxiObjk5+89t3U/nY1iQLQx
MWykSUqG7kM5TqaXeLA8dR9PUTg68vdNK6TBaZFjK7WrgeltIgchu6yI5hakFEFf
cJZdHym0pv7Vi3GXH8FAlBdU7eaUGB2ox9XBUhakOIUC7bcIuOK5Kb/qaGkdzUXa
ood9I+kkSHvTrOWu9mRw0Sb0pZJgx+GRq5jgdqn3ly3k1pAabYE=
=28f1
-END PGP SIGNATURE-

Bug#1041718: ITP: keepassxc-proxy-client -- Library to access a running KeepassXC instance

[Antonio Russo]

Package: wnpp
Severity: wishlist
Owner: Antonio Russo 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: keepassxc-proxy-client
  Version : 0.1.6
  Upstream Contact: Henrik Böving
* URL : https://github.com/hargoniX/keepassxc-proxy-client
* License : ISC
  Programming Lang: Python
  Description : Library to access a running KeepassXC instance

 KeepassXC is a password manager which exposes an interface to allow
 access-controlled retrieval of passwords from its secure storage.
 keepassxc-proxy-client is a Python library that can speak this
 protocol, allowing programmatic access to passwords in the
 database.  This packages also includes a simple CLI client built
 using the library.

Best,
Antonio Russo

Bug#1041733: ITP: rust-linemux -- asynchronous, multiplexed file tailing

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-linemux
  Version : 0.3.0
  Upstream Contact: Jon Magnuson 
* URL : https://github.com/jmagnuson/linemux
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : asynchronous, multiplexed file tailing

 linemux is a library providing asynchronous, multiplexed tailing
 for (namely log) files.
 .
 Also available is the underlying file event-stream
 (driven by notify)
 that can register non-existent files.

This package is needed for tailspin (bug#1041717) and safe-vdash
(bug#1009781).
It will be maintained in the collaborative debian section of salsa, at
.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS8DncACgkQLHwxRsGg
ASEnVg/9Evn2uuNe5P7JwBOAcrbBoWLsAlViW7cr8ZpbenTAEeqVRuEGskMsIrR1
7Q5bqtXCxJk8yNZggXnJmQZvCTPjJ8YG/05TT5M+LeNQszQgnJqeXtDYXos6KGbX
YHGcCKHeN2HXAm9XftFPu+gtEZqxVFF/ghtH1wsOpCj7LXCzV6a9iVfEErevZPBU
T3eM1KXCwqM3U2mV2X/FvRcgkTtRIQEiC98JeLRRK6sGS6uiuaItT+WDq2NomuJE
siJO5pTELWuCZpMjAjVYfIE/emp7alp3NlepwPxENbgoxMza7GSbeecDqMrtsLR7
DzdmbzOfgVqzeYtfR50oiQ4hQG3O/l0uzAVEno7wilQCh+IphtMTBVcw3NFfu7Qk
RE28ObdHQPELCfswUXmqcAc8k1nzqIivyr0mRTbYqaek4tpaPPhK2SGKWR+sY04q
Far/c9wmo/AhgRq1u/NMN/1O/FOkJ8nx4fUaKSLFLO5Jcewmm0buNXA9Re1v1piS
3coRb2fi94WzwYTJ69Iwq4y0HvpZIRGUO5sLgkdjFyr4QXr02HIPUHmECr/jd61z
FaMmie9jXQADkQkcRFyl6/EHP6rAVZiuAdsQidRzlnokQIybpxYLcEzv3lb+emN7
lkLJLwx1+l/J/iG4nLAF4+375Z/E69X+IReJcIr6EKoXxFyy1jg=
=Tkfc
-END PGP SIGNATURE-

Re: HFS/HFS+ are insecure

[Ben Hutchings]

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.



signature.asc
Description: This is a digitally signed message part

Bug#1041747: ITP: golang-github-containers-libtrust -- Primitives for identity and authorization

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-libtrust
  Version : 0.0~git20230121.c1716e8-1
  Upstream Author : Containers
* URL : https://github.com/containers/libtrust
* License : Apache-2.0
  Programming Lang: Go
  Description : Primitives for identity and authorization

 Libtrust is library for managing authentication and authorization using
 public key cryptography.
 .
 Authentication is handled using the identity attached to the public key.
 Libtrust provides multiple methods to prove possession of the private
 key associated with an identity.
 .
  * TLS x509 certificates
  * Signature verification
  * Key Challenge
 .
 Authorization and access control is managed through a distributed trust
 graph. Trust servers are used as the authorities of the trust graph and
 allow caching portions of the graph for faster access.
 .
 This package contains a fork of Docker's libtrust that is being worked
 by the github containers commnuity.