On Sa, 22.07.23 07:01, Matthew Garrett (mj...@srcf.ucam.org) wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>
On Jul 24, 2023, at 12:11 PM, Eric Sandeen wrote:
And frankly that is some of my motivation to find an improvement here. A
small cadre of filesystem developers are near the breaking point trying
to keep up with an army of machines running syzkaller.
There’s also a large flow-on effect to those
On Jul 24, 2023, at 7:47 AM, Richard W.M. Jones wrote:
On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
I saw that libguestfs has a guestmount(1) tool, and I think this could be
a potential solution. An exploit against the kernel FS driver would only
grant access to a KVM
> On Jul 24, 2023, at 7:17 AM, Michael Catanzaro wrote:
>
> On Sun, Jul 23 2023 at 11:18:45 PM -0400, Demi Marie Obenour
> wrote:
>> Then the mount needs to be done in a sandbox, such as a KVM guest or
>> sandboxed userspace process.
>
> Hmmm... I don't think traditional sandboxing
On 7/24/23 10:40 PM, Demi Marie Obenour wrote:
On 7/24/23 15:11, Eric Sandeen wrote:
On 7/23/23 7:22 PM, Steve Grubb wrote:
On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote:
A discussion within Debian again brought up the problem that:
1) Automounting of removable media
On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote:
> On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> > If I have a USB flash stick I plug in every day, it shouldn't ask me
> > about that after the first time I use it.
>
> Based on this "threat model"
On 7/24/23 15:11, Eric Sandeen wrote:
> On 7/23/23 7:22 PM, Steve Grubb wrote:
>> On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote:
>>> A discussion within Debian again brought up the problem that:
>>>
>>> 1) Automounting of removable media exposes the kernel to a lot of
>>>
On 7/23/23 7:22 PM, Steve Grubb wrote:
On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote:
A discussion within Debian again brought up the problem that:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
2) Kernel upstream are not terribly concerned
On 7/24/23 10:00 AM, Daniel P. Berrangé wrote:
On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
...
I still believe that mounting should _not_ be automatic, though, because
it could have side-effects (such as replaying the FS journal) that might
not be wanted. To prevent
Richard W.M. Jones wrote:
> A bit in the superblock marks the filesystem as clean or dirty, and
> that has nothing to do with whether it is malicious.
You mean we cannot rely on https://www.ietf.org/rfc/rfc3514.txt for this?
;-)
Kevin Kofler
On Mon, Jul 24, 2023 at 12:08:00PM -0400, Solomon Peachy wrote:
> On Mon, Jul 24, 2023 at 04:51:38PM +0100, Richard W.M. Jones wrote:
> > You don't actually need to do any of this if you're using libguestfs,
> > because the worst that can happen is the filesystem will pwn the
> > kernel inside the
On Mon, Jul 24, 2023 at 04:51:38PM +0100, Richard W.M. Jones wrote:
> You don't actually need to do any of this if you're using libguestfs,
> because the worst that can happen is the filesystem will pwn the
> kernel inside the KVM appliance (which is just a userspace process, so
> you can kill
Am 23.07.23 um 09:35 schrieb Vitaly Zaitsev via devel:
On 22/07/2023 08:01, Matthew Garrett wrote:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
Disable automatic mount by default. Problem solved.
We use a whitelist approach here based
on usbguard
On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote:
> On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> > If I acquire a new USB flash stick I've never plugged in before, I
> > don't want it auto-mounting before I can wipe & reformat it.
>
> Honestly,
On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> If I have a USB flash stick I plug in every day, it shouldn't ask me
> about that after the first time I use it.
Based on this "threat model" all an attacker has to do then is
snag/modify/replace your existing drive and then
On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
> On 7/24/23 08:47, Richard W.M. Jones wrote:
> > On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote:
> >> On 7/23/23 12:10, Solomon Peachy via devel wrote:
> >>> On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal
On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote:
> I saw that libguestfs has a guestmount(1) tool, and I think this could be
> a potential solution. An exploit against the kernel FS driver would only
> grant access to a KVM guest, and the QEMU process can be tightly sandboxed
>
On Mon, Jul 24 2023 at 10:08:50 AM -0400, Demi Marie Obenour
wrote:
I saw that libguestfs has a guestmount(1) tool, and I think this
could be
a potential solution. An exploit against the kernel FS driver would
only
grant access to a KVM guest, and the QEMU process can be tightly
sandboxed
On Sun, Jul 23 2023 at 11:18:45 PM -0400, Demi Marie Obenour
wrote:
Then the mount needs to be done in a sandbox, such as a KVM guest or
sandboxed userspace process.
Hmmm... I don't think traditional sandboxing accomplishes anything
here, because we're trying to protect against kernel bugs,
On 7/24/23 08:47, Richard W.M. Jones wrote:
> On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote:
>> On 7/23/23 12:10, Solomon Peachy via devel wrote:
>>> On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote:
> If the system administrator wants to mount $UNCOMMONFS, they
On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote:
> On 7/23/23 12:10, Solomon Peachy via devel wrote:
> > On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote:
> >>> If the system administrator wants to mount $UNCOMMONFS, they should be
> >>> able to do so without hassle,
On 7/23/23 11:05, Eric Sandeen wrote:
> On 7/22/23 7:57 AM, Michael Catanzaro wrote:
>> I've been thinking about this for a while. The status quo is really awful.
>>
>> On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek
>> wrote:
>>> A bigger problem I see, is that if a user
On 7/23/23 12:10, Solomon Peachy via devel wrote:
> On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote:
>>> If the system administrator wants to mount $UNCOMMONFS, they should be
>>> able to do so without hassle, but that doesn't mean that a normal user
>>> who got handed a sketchy USB
On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>
On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote:
> > If the system administrator wants to mount $UNCOMMONFS, they should be
> > able to do so without hassle, but that doesn't mean that a normal user
> > who got handed a sketchy USB stick at a conference should be able to do
> > so with
On Sun, Jul 23, 2023 at 11:08 AM Eric Sandeen wrote:
>
> On 7/22/23 9:12 AM, Neal Gompa wrote:
> > On Sat, Jul 22, 2023 at 9:53 AM Florian Weimer wrote:
> >>
> >> * Matthew Garrett:
> >>
> >>> a) Does this seem like a good idea?
> >>> b) If so, is dealing with it via udev rules the right
On 7/22/23 9:12 AM, Neal Gompa wrote:
On Sat, Jul 22, 2023 at 9:53 AM Florian Weimer wrote:
* Matthew Garrett:
a) Does this seem like a good idea?
b) If so, is dealing with it via udev rules the right approach? This way
seems desktop-agnostic
c) Where should it ship, and what should the
On 7/22/23 7:57 AM, Michael Catanzaro wrote:
I've been thinking about this for a while. The status quo is really awful.
On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek
wrote:
A bigger problem I see, is that if a user plugins in a usb stick,
expecting to make use of it,
On 22/07/2023 08:01, Matthew Garrett wrote:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
Disable automatic mount by default. Problem solved.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On Sat, Jul 22, 2023 at 10:32:01AM +0200, drago01 wrote:
> Which file systems are considered uncommon in that context? And aren't most
> attacks based on file systems used by windows, which makes them "common" ?
> (Extfat, NTFS, VFAT)
Any attack here is going to be OS-specific - a vulnerability
On 7/22/23 08:57, Michael Catanzaro wrote:
> I've been thinking about this for a while. The status quo is really
> awful.
>
> On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek
> wrote:
>> A bigger problem I see, is that if a user plugins in a usb stick,
>> expecting to make
On Sat, Jul 22, 2023 at 10:12:33AM -0400, Neal Gompa wrote:
> Several years ago, SUSE distributions moved to disabling the modules
> by default for a number of filesystems, but making it pretty easy to
> turn them back on:
> https://github.com/openSUSE/suse-module-tools/pull/5
The problem there
On Sat, Jul 22, 2023 at 9:53 AM Florian Weimer wrote:
>
> * Matthew Garrett:
>
> > a) Does this seem like a good idea?
> > b) If so, is dealing with it via udev rules the right approach? This way
> > seems desktop-agnostic
> > c) Where should it ship, and what should the process be for disabling
* Matthew Garrett:
> a) Does this seem like a good idea?
> b) If so, is dealing with it via udev rules the right approach? This way
> seems desktop-agnostic
> c) Where should it ship, and what should the process be for disabling it
> for people who need this functionality?
Maybe a first step
I've been thinking about this for a while. The status quo is really
awful.
On Sat, Jul 22 2023 at 11:31:22 AM +, Zbigniew Jędrzejewski-Szmek
wrote:
A bigger problem I see, is that if a user plugins in a usb stick,
expecting to make use of it, and it's not automounted without any
On Sat, Jul 22, 2023 at 07:01:34AM +0100, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>
On Sat, Jul 22, 2023 at 07:01:34AM +0100, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>
On Saturday, July 22, 2023, Matthew Garrett wrote:
> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are
A discussion within Debian again brought up the problem that:
1) Automounting of removable media exposes the kernel to a lot of
untrusted input
2) Kernel upstream are not terribly concerned with ensuring that kernel
filesystems are resilient against deliberately malformed filesystems so
are
39 matches
Mail list logo
