Re: Restricting automounting of uncommon filesystems?

[Lennart Poettering]

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
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"

I am not convinced that the udev db is really a great place for such
configuration that is not really related to devices itself, but more
about local policy decisions.

What I think is important to keep in mind is that /bin/mount doesn't
check the udev db (and probably shouldn't) when determining the fstype
to mount when using "-t auto" (which is implied if -t is omitted). I
think it would make sense to devise a mechanism that automatic
mounting for removable disks is covered the same way as "mount -t
auto" by such an allowlist of fstypes.

My preferred mechanism to implement what you are asking for is what
I proposed here:

https://github.com/util-linux/util-linux/issues/1969

And as it turns out Karel actually implemented this recently, see
https://github.com/util-linux/util-linux/commit/1592425a0a1472db3168cd9247f001d7c5dd84b6.

I think it would be a good idea to build on that, i.e. make udisks
just set that mount option to a useful allowlist, and then be done
with it?

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

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 running production systems and 
what they have to patch and at what pace.

In the current model, where we enable the NTFS (or BeFS, or UFS, or HFS, or 
whatever) file system, every time that has some CVE, we get to release a 
security advisory saying “everybody go update your kernels” and for 99.99% of 
users, it’s code they don’t use, and don’t *want* to even ever have loaded. The 
CIS Hardening Benchmarks all start with “blacklist modules for file systems you 
don’t need”, and module blacklisting is both not an ideal name for the 
functionality, and not exactly a foolproof method.

For a lot of users we are currently:
- likely making them patch needlessly, as it’s code they don’t rely on
- or training them that Important security updates aren’t actually always 
Important, and maybe they can not pay attention to them.

I *really* dislike the latter. The clarity of “you have this software 
installed, there is an Important update to it, this means you must update 
within X time” is wonderful.

One idea we’ve been throwing around is to put all the non-essential (i.e. 
everything but vfat and xfs) file system modules in a different subpackage, and 
sign the modules with a different key, and not trusting that key by default. 
Thus we could issue security advisories just for that subpackage, as well as 
clearly state the level of trust one should place in the code in question.

Combine that with a libguestfs approach with a separate kernel package for its 
guest, and lazy people like me could probably not have to reboot their 
laptop/desktop as often, while simultaneously being more protected from random 
malicious flash drives.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

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 guest, and the QEMU process can be tightly sandboxed
by means such as seccomp and SELinux.

Right.  guestmount does however use an unholy combination of FUSE and
proxying requests through the KVM guest so this wouldn't be very fast :-/

OTOH it may be fine for the overwhelming majority of use cases, and the 
tradeoff of better hardened systems could also be worth it.

I’ve seen more than one implementation of “Run a Linux container on macOS” that 
ends up using ssh for the console and sshfs as the way to get data back and 
forth… and people seem to be fine with it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Smith, Stewart via devel]

> 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 accomplishes anything
> here, because we're trying to protect against kernel bugs, not
> userspace bugs, and if the kernel is compromised then you escape the
> sandbox. A KVM virtual machine would solve that, certainly, but that
> sounds really complicated to do? We don't have any precedent for
> spinning up virtual machines to perform normal desktop operations.
> Doesn't that require hardware support anyway? i.e. virtualization might
> be disabled at the firmware level?

Many (most?) cloud environments don’t expose a nested virt capability. That 
being said, even qemu tcg could be a better option for confinement and deliver 
perfectly acceptable performance for a bunch of the use cases.

It’s convenient for me, the user, to be able to use normal Linux utilities to 
read and write files on media for increasingly “oh goodness this makes me feel 
old, I swear that was current just last week” old machines, I don’t exactly 
need multiple hundreds of megabytes per second of IO to that media, I much 
prefer that a random disk image of a 1990s era Mac System Software Beta has as 
many obstacles as possible to being able to inject code into the kernel that I 
also use to log into my bank.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Eric Sandeen]

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 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 mostly not proactively looking for bugs there
3) Uncommonly used filesystems are less likely to be tested against
adverse input in the real world and so are more likely to contain
exploitable bugs

There are various cases where people do need to make use of uncommon
filesystems, but the majority of them aren't related to removable media.
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
shouldn't be automounted, which means something like:

SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
# repeat as necessary for anything else that shouldn't be automounted
LABEL="udisks_insecure_fs_end"

ought to be enough. So:

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?

Long-term I'd love to see more work put into having FUSE support for
these and leaving the in-kernel fs to stuff we know is trustworthy, but
that's rather more work.


If "a malicious input can't cause problems" is the threshold for
trustworthy, I'm not sure we have any trustworthy filesystems as this point.

https://syzkaller.appspot.com/upstream/s/ext4
https://syzkaller.appspot.com/upstream/s/xfs
https://syzkaller.appspot.com/upstream/s/btrfs
https://syzkaller.appspot.com/upstream/s/fat


A while back, I wrote the fsfuzzer specifically to find, in a repeatable way,
filesystem bugs so they can be fixed:

https://github.com/stevegrubb/fsfuzzer

It does not support all filesystems, but it is easy to add support through
adding the correct mounter to the scrips. It has found *so* *many* filesystem
bugs over time.


That was awesome, back in the day! syzbot/syzcaller is the new shiny
here though, finding filesystem flaws day after day that (with all due
respect) fsfuzzer could never have reached (think: fuzzing metadata and
then fixing up the checksum so it passes initial validation on read.)

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.

-Eric


How much of the problem is the C programming language itself?  I’m NOT
suggesting that you rewrite your filesystem in Rust; that would be an
extremely unreasonable request.  I’m merely trying to figure out how
much of this is a case of “filesystems are hard” and how much of this
is C providing essentially no help.


Well, this has been discussed but it's obviously not a short-term 
solution. :) (Nor would Rust be a panacea. Some of the problems may be 
mitigated by a language like Rust, but certainly not all of them.)


I think it's a little bit of both scenarios, tbh.

-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Daniel P . Berrangé]

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" all an attacker has to do then is 
> snag/modify/replace your existing drive and then they can pwn your 
> system.  That's probably much easier to accomplish than getting you to 
> insert a previously-unseen device (the latter has a lot of awareness 
> around it, but the "of course I trust this one, it's mine!" will get you 
> pwned.)

While in-person attackers are real, IMHO that are not the big risk
factor for the general populace. I wasn't claiming this was a perfect
solution, just that it addresses some easy low hanging fruit, where
you have no clue what will be on a new drive you receive (whether
purchased online, or as a swag at a trade show, etc). 

> (Besides, how are you to distinguish the exact stick?  Most of the stuff 
> I have lying around here reports the same generic vendor/product/serial 
> number.  And drive/volume labels are notoriously unreliable.)

Yes there are some lame vendors, that don't burn unique serials,
which will make it imperfect. IMHO it is still credible to use
the vendor/product/serial despite that.



> > 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, what makes more sense to me is treat this whole thing purely 
> as a usability problem.  Upon insertion, prompt the user to "mount, 
> mount reat-only, check, ignore", because at least then we'd get an 
> really easy method of fscking a disk without having to do the whole 
> unmount dance.  It also provides a mechanism to supply user feedback (eg 
> showing fsck results, or the XFS case where you _have_ to mount the 
> filesystem to replay the journal before an fsck can be safely run)

If you prompt a user every single time, all that results is
training the user to press 'yes' without looking. To be useful
the prompts need to only happen in unusual circumstances, that
are infrequent enough to avoid training an instinctive response.

> Again, let's be realistic about the threat models here -- the 
> overwhelmingly common situations are accidental corruption due to 
> improper shutdown/ejection, and malicious files on a well-formed 
> filesystem (eg ransomware or something that's banking on users having we 
> passwordless sudo in place, or curl https://url/setup.sh | sudo bash)

Accidental corruption is indeed important, and wouldn't be solved
by prompting. Protecting against that I think requires taking the
libguestfs approach of mounting in an isolated guest OS kernel.

In terms of malicious files, I think that not trusting newly seen
devices is a valid strategy. There's plenty of documented cases
where new  devices had malware pre-installed. Re-formatting newly
seen devices means the user only needs worry about their own usage
from that point onwards, bringing in malware.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Demi Marie Obenour]

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
>>> untrusted input
>>> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>>> filesystems are resilient against deliberately malformed filesystems so
>>> are mostly not proactively looking for bugs there
>>> 3) Uncommonly used filesystems are less likely to be tested against
>>> adverse input in the real world and so are more likely to contain
>>> exploitable bugs
>>>
>>> There are various cases where people do need to make use of uncommon
>>> filesystems, but the majority of them aren't related to removable media.
>>> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
>>> shouldn't be automounted, which means something like:
>>>
>>> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
>>> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
>>> # repeat as necessary for anything else that shouldn't be automounted
>>> LABEL="udisks_insecure_fs_end"
>>>
>>> ought to be enough. So:
>>>
>>> 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?
>>>
>>> Long-term I'd love to see more work put into having FUSE support for
>>> these and leaving the in-kernel fs to stuff we know is trustworthy, but
>>> that's rather more work.
> 
> If "a malicious input can't cause problems" is the threshold for 
> trustworthy, I'm not sure we have any trustworthy filesystems as this point.
> 
> https://syzkaller.appspot.com/upstream/s/ext4
> https://syzkaller.appspot.com/upstream/s/xfs
> https://syzkaller.appspot.com/upstream/s/btrfs
> https://syzkaller.appspot.com/upstream/s/fat
> 
>> A while back, I wrote the fsfuzzer specifically to find, in a repeatable way,
>> filesystem bugs so they can be fixed:
>>
>> https://github.com/stevegrubb/fsfuzzer
>>
>> It does not support all filesystems, but it is easy to add support through
>> adding the correct mounter to the scrips. It has found *so* *many* filesystem
>> bugs over time.
> 
> That was awesome, back in the day! syzbot/syzcaller is the new shiny 
> here though, finding filesystem flaws day after day that (with all due 
> respect) fsfuzzer could never have reached (think: fuzzing metadata and 
> then fixing up the checksum so it passes initial validation on read.)
> 
> 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.
> 
> -Eric

How much of the problem is the C programming language itself?  I’m NOT
suggesting that you rewrite your filesystem in Rust; that would be an
extremely unreasonable request.  I’m merely trying to figure out how
much of this is a case of “filesystems are hard” and how much of this
is C providing essentially no help.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Eric Sandeen]

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 with ensuring that kernel
filesystems are resilient against deliberately malformed filesystems so
are mostly not proactively looking for bugs there
3) Uncommonly used filesystems are less likely to be tested against
adverse input in the real world and so are more likely to contain
exploitable bugs

There are various cases where people do need to make use of uncommon
filesystems, but the majority of them aren't related to removable media.
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
shouldn't be automounted, which means something like:

SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
# repeat as necessary for anything else that shouldn't be automounted
LABEL="udisks_insecure_fs_end"

ought to be enough. So:

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?

Long-term I'd love to see more work put into having FUSE support for
these and leaving the in-kernel fs to stuff we know is trustworthy, but
that's rather more work.


If "a malicious input can't cause problems" is the threshold for 
trustworthy, I'm not sure we have any trustworthy filesystems as this point.


https://syzkaller.appspot.com/upstream/s/ext4
https://syzkaller.appspot.com/upstream/s/xfs
https://syzkaller.appspot.com/upstream/s/btrfs
https://syzkaller.appspot.com/upstream/s/fat


A while back, I wrote the fsfuzzer specifically to find, in a repeatable way,
filesystem bugs so they can be fixed:

https://github.com/stevegrubb/fsfuzzer

It does not support all filesystems, but it is easy to add support through
adding the correct mounter to the scrips. It has found *so* *many* filesystem
bugs over time.


That was awesome, back in the day! syzbot/syzcaller is the new shiny 
here though, finding filesystem flaws day after day that (with all due 
respect) fsfuzzer could never have reached (think: fuzzing metadata and 
then fixing up the checksum so it passes initial validation on read.)


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.


-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Eric Sandeen]

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 prompt fatigue, Fedora could offer to remember
the user’s choice.


Remember the choice per device.

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.

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.


FWIW, OSX does this today.

-Eric


With regards,
Daniel

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Richard W.M. Jones]

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 KVM appliance (which is just a userspace process, so
> > you can kill it).
> 
> But if that kernel is pwn3d, won't that still allow arbitrary data to be 
> passed out to the host?  (I confess to knowing very little about the 
> guts of libguestfs)

If the malicious filesystem managed to execute code in the appliance,
it would be able to feed custom data back to the host when the host
called APIs like 'guestfs_read_file' to read a file, but that's just
the same as a regular filesystem having files with data in them.

There are probably more complex multi-step exploits possible, but it's
still vastly safer than having your host kernel being rooted which is
instant game over.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Solomon Peachy via devel]

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

But if that kernel is pwn3d, won't that still allow arbitrary data to be 
passed out to the host?  (I confess to knowing very little about the 
guts of libguestfs)

> A bit in the superblock marks the filesystem as clean or dirty, and
> that has nothing to do with whether it is malicious.

Yep. I'm just saying that if the filesystem is marked as dirty, then 
prompting the user what to do is a good idea -- After all, we *know* the 
filesystem integrity is questionable, and mounting it might cause 
unintented side effects.  (ie not p3nage, but instead the far more 
common threat of corruption or data loss)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Leon Fauster via devel]

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 daemon (hw centered), and

# cat /etc/dconf/db/local.d/s-media-automount
[org/gnome/desktop/media-handling]
automount=false
automount-open=false

Our scenario is clearly modelled around an user
in front of a GUI. So, it tackles it in different
layers and the actual fs attack vector is not addressed.

Should a "middleware" based on guestmount just check
for the integrity of the fs or keeping it in such
sandbox?

--
Leon








___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Richard W.M. Jones]

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, what makes more sense to me is treat this whole thing purely 
> as a usability problem.  Upon insertion, prompt the user to "mount, 
> mount reat-only, check, ignore", because at least then we'd get an 
> really easy method of fscking a disk without having to do the whole 
> unmount dance.  It also provides a mechanism to supply user feedback (eg 
> showing fsck results, or the XFS case where you _have_ to mount the 
> filesystem to replay the journal before an fsck can be safely run)

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

> If the filesystem is dirty, the dialog always is displayed (with an 
> appropriate message recommending fsck), but if it's clean, the user can 
> dismiss the dialog with prejudice and have it always accept that drive 
> in the future.

A bit in the superblock marks the filesystem as clean or dirty, and
that has nothing to do with whether it is malicious.

> We can also provide a hot-key (eg hold down shift when inserting the 
> drive) to tell the system to always show the prompt even for previously 
> whitelisted devices.
> 
> This IMO improves the general usability of the system, instead of making 
> things universally worse, while simultaneously providing the hooks 
> necessary to implement better security.
> 
> Again, let's be realistic about the threat models here -- the 
> overwhelmingly common situations are accidental corruption due to 
> improper shutdown/ejection, and malicious files on a well-formed 
> filesystem (eg ransomware or something that's banking on users having we 
> passwordless sudo in place, or curl https://url/setup.sh | sudo bash) 

I do agree here.

> So let's make things better for those before worry about mitigating APTs 
> that need lots of system-specific awareness in order for an attack to 
> succeed?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Solomon Peachy via devel]

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 they can pwn your 
system.  That's probably much easier to accomplish than getting you to 
insert a previously-unseen device (the latter has a lot of awareness 
around it, but the "of course I trust this one, it's mine!" will get you 
pwned.)

(Besides, how are you to distinguish the exact stick?  Most of the stuff 
I have lying around here reports the same generic vendor/product/serial 
number.  And drive/volume labels are notoriously unreliable.)

> 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, what makes more sense to me is treat this whole thing purely 
as a usability problem.  Upon insertion, prompt the user to "mount, 
mount reat-only, check, ignore", because at least then we'd get an 
really easy method of fscking a disk without having to do the whole 
unmount dance.  It also provides a mechanism to supply user feedback (eg 
showing fsck results, or the XFS case where you _have_ to mount the 
filesystem to replay the journal before an fsck can be safely run)

If the filesystem is dirty, the dialog always is displayed (with an 
appropriate message recommending fsck), but if it's clean, the user can 
dismiss the dialog with prejudice and have it always accept that drive 
in the future.

We can also provide a hot-key (eg hold down shift when inserting the 
drive) to tell the system to always show the prompt even for previously 
whitelisted devices.

This IMO improves the general usability of the system, instead of making 
things universally worse, while simultaneously providing the hooks 
necessary to implement better security.

Again, let's be realistic about the threat models here -- the 
overwhelmingly common situations are accidental corruption due to 
improper shutdown/ejection, and malicious files on a well-formed 
filesystem (eg ransomware or something that's banking on users having we 
passwordless sudo in place, or curl https://url/setup.sh | sudo bash) 

So let's make things better for those before worry about mitigating APTs 
that need lots of system-specific awareness in order for an attack to 
succeed?

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Daniel P . Berrangé]

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 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 no restrictions at all.
> >
> 
>  So then some kind of configuration to udisks2 to have a similar effect?
> >>>
> >>> And we're right back at square one, with the *overwhelmingly* common case 
> >>> of a single-user system whose "admin" is sitting in front of the system.
> >>>
> >>> Of _course_ they want to mount the disk.  It's why they plugged it in, 
> >>> and they don't give two hoots if it's a "common filesystem" or not.
> >>>
> >>> (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
> >>> because fat32 sucks and I can't rely on exfat on all systems I need to 
> >>> interoperate with)
> >>>
> >>> And let's be realistic here -- the overwhelmingly common threat model 
> >>> here is that there are untrusted files on a correctly-formed filesystem.  
> >>> Bad guys rarely need or care to get root on the system; what they're 
> >>> after requires normal, non-elevated user permissions.
> >>>
> >>> Prompting users 'are you sure you want to use this device' will turn a 
> >>> "yes" into an automatic reflex.  Not automounting by default will just 
> >>> add another thing to the "things to change on default fedora 
> >>> installations" lists out there (ie right after the "enable freshrpms and 
> >>> install modern video codecs" step), becuase it's a usability nightmare.
> >>>
> >>> In the "usability vs security" tradeoff, usability/convenience *always* 
> >>> wins unless you're at a place that has armed guards at the door with 
> >>> instructions to shoot first.
> >>>
> >>>  - Solomon
> >>
> >> Then the mount needs to be done in a sandbox, such as a KVM guest or
> >> sandboxed userspace process.
> > 
> > This is what libguestfs does (KVM guest).
> > 
> > Rich.
> 
> 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
> by means such as seccomp and SELinux.
> 
> 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 prompt fatigue, Fedora could offer to remember
> the user’s choice.

Remember the choice per device.

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.

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.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Richard W.M. Jones]

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
> by means such as seccomp and SELinux.

Right.  guestmount does however use an unholy combination of FUSE and
proxying requests through the KVM guest so this wouldn't be very fast :-/

There's a native API which is much faster, which might be used by gvfs
(or whatever the gnome abstract filesystem thing is called).  I think
that would allow GNOME's file manager to work, and would be a lot
faster.

Rich.

> 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 prompt fatigue, Fedora could offer to remember
> the user’s choice.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Michael Catanzaro]

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

by means such as seccomp and SELinux.


Ah, interesting. Maybe something like that would work, indeed

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Michael Catanzaro]

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, not 
userspace bugs, and if the kernel is compromised then you escape the 
sandbox. A KVM virtual machine would solve that, certainly, but that 
sounds really complicated to do? We don't have any precedent for 
spinning up virtual machines to perform normal desktop operations. 
Doesn't that require hardware support anyway? i.e. virtualization might 
be disabled at the firmware level?


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Demi Marie Obenour]

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 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 no restrictions at all.
>

 So then some kind of configuration to udisks2 to have a similar effect?
>>>
>>> And we're right back at square one, with the *overwhelmingly* common case 
>>> of a single-user system whose "admin" is sitting in front of the system.
>>>
>>> Of _course_ they want to mount the disk.  It's why they plugged it in, 
>>> and they don't give two hoots if it's a "common filesystem" or not.
>>>
>>> (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
>>> because fat32 sucks and I can't rely on exfat on all systems I need to 
>>> interoperate with)
>>>
>>> And let's be realistic here -- the overwhelmingly common threat model 
>>> here is that there are untrusted files on a correctly-formed filesystem.  
>>> Bad guys rarely need or care to get root on the system; what they're 
>>> after requires normal, non-elevated user permissions.
>>>
>>> Prompting users 'are you sure you want to use this device' will turn a 
>>> "yes" into an automatic reflex.  Not automounting by default will just 
>>> add another thing to the "things to change on default fedora 
>>> installations" lists out there (ie right after the "enable freshrpms and 
>>> install modern video codecs" step), becuase it's a usability nightmare.
>>>
>>> In the "usability vs security" tradeoff, usability/convenience *always* 
>>> wins unless you're at a place that has armed guards at the door with 
>>> instructions to shoot first.
>>>
>>>  - Solomon
>>
>> Then the mount needs to be done in a sandbox, such as a KVM guest or
>> sandboxed userspace process.
> 
> This is what libguestfs does (KVM guest).
> 
> Rich.

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
by means such as seccomp and SELinux.

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 prompt fatigue, Fedora could offer to remember
the user’s choice.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Richard W.M. Jones]

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, 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 no restrictions at all.
> >>>
> >>
> >> So then some kind of configuration to udisks2 to have a similar effect?
> > 
> > And we're right back at square one, with the *overwhelmingly* common case 
> > of a single-user system whose "admin" is sitting in front of the system.
> > 
> > Of _course_ they want to mount the disk.  It's why they plugged it in, 
> > and they don't give two hoots if it's a "common filesystem" or not.
> > 
> > (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
> > because fat32 sucks and I can't rely on exfat on all systems I need to 
> > interoperate with)
> > 
> > And let's be realistic here -- the overwhelmingly common threat model 
> > here is that there are untrusted files on a correctly-formed filesystem.  
> > Bad guys rarely need or care to get root on the system; what they're 
> > after requires normal, non-elevated user permissions.
> > 
> > Prompting users 'are you sure you want to use this device' will turn a 
> > "yes" into an automatic reflex.  Not automounting by default will just 
> > add another thing to the "things to change on default fedora 
> > installations" lists out there (ie right after the "enable freshrpms and 
> > install modern video codecs" step), becuase it's a usability nightmare.
> > 
> > In the "usability vs security" tradeoff, usability/convenience *always* 
> > wins unless you're at a place that has armed guards at the door with 
> > instructions to shoot first.
> > 
> >  - Solomon
> 
> Then the mount needs to be done in a sandbox, such as a KVM guest or
> sandboxed userspace process.

This is what libguestfs does (KVM guest).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Demi Marie Obenour]

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 plugins in a usb stick,
>>> expecting to make use of it, and it's not automounted without any
>>> explanation, they are most likely to just click for it to be mounted,
>>> or to even issue an explicit 'mount', defeating the whole protection.
>>
>> Yup, there's the problem. The user will almost always mount it manually, 
>> so disabling automount seems pointless.
>>
>>> A more reasonable UI would be to display a pop-up that says "Device
>>> ASDF uses file system AmigaFS 1982 which is not well supported. See
>>> https://some.link/ for details. Do you want to a) mount once, b) not
>>> mount, c) mount this fs type always?". This would require some work
>>> in DE.
>>
>> The UI would have to not mention technical details like the name of the 
>> filesystem. Also, warning a user that the filesystem is not 
>> "well-supported" is also not likely to accomplish much. The user plugged 
>> in the USB stick in order to look at files, and will almost always 
>> choose to do so if presented with the option. Even if we warn that the 
>> device may be malicious (which we don't actually know), users will still 
>> just think about it and decide "probably not, I want to see my files."
>>
>> The desktop security model assumes the kernel is robust to malformed 
>> filesystems and removing that assumption is just not workable. This 
>> development mindset might be prevalent among kernel developers, but it's 
>> not acceptable for desktop users.  Filesystems that are not designed to 
>> be robust to untrusted input should be disabled outright and not 
>> supported at all. I'm not sure how practical this actually is, though, 
>> because I think it would probably entail disabling common filesystems 
>> (ext4? xfs? btrfs?) in addition to uncommon filesystems. Starting with 
>> disabling uncommon filesystems is better than nothing, though.
> 
> mount is a privileged operation in the kernel; when system configuration 
> works around that to allow non-trusted users to initiate a mount, that 
> breaks the restrictions that the kernel intentionally put on the ability 
> to ingest a stream of untrusted data from a block device.
> 
> Filesystems generally *do* care about malformed input, but they do so in 
> the context of the security model that the kernel defines.
> 
> As an example, XFS goes to great lengths to validate input, and placing 
> checksums on every piece of metadata is a big part of that. In the real 
> world, this validation catches and handles the vast majority of 
> malformed/corrupted input that XFS should expect to see.
> 
> Other filesystems have similar validation, with similar assumptions.
> 
> But when fuzzers intentionally malform metadata and then fix up the 
> checksum to look valid, this is something that would never happen 
> organically; it is an intentionally malicious work-around to the 
> existing mechanism. But again, mount is supposed to be a privileged 
> operation, so if the system administrator decides to mount the USB drive 
> they found in the parking lot, that's on them, and not a security issue. 
> They are root, after all.

Unfortunately, this original threat model is out of date.  kernel_lockdown(7)
explicitly aims to prevent root from compromising the kernel, which means
that malformed filesystem images are now in scope, for all filesystems.
If a filesystem driver is not secure against malicious filesystem images,
then using it should fail if the kernel is locked down, just like loading
an unsigned kernel module does.

> I wholeheartedly support any effort to restrict (by default) 
> auto-mounting to a smaller set of filesystems that could reasonably be 
> expected to be found on removable media (isofs, fat, exfat ...) and shut 
> off all the rest to limit the attack surface here.

Disks used for backups will often be formatted with ext4, XFS, or BTRFS,
and it should be possible to safely read the contents of a backup even if
the backup source was compromised.

> This issue and the 
> associated CVEs that get raised have been consuming an inordinate amount 
> of time from a very limited set of filesystem developers.
> 
> -Eric
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Demi Marie Obenour]

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 stick at a conference should be able to do
>>> so with no restrictions at all.
>>>
>>
>> So then some kind of configuration to udisks2 to have a similar effect?
> 
> And we're right back at square one, with the *overwhelmingly* common case 
> of a single-user system whose "admin" is sitting in front of the system.
> 
> Of _course_ they want to mount the disk.  It's why they plugged it in, 
> and they don't give two hoots if it's a "common filesystem" or not.
> 
> (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
> because fat32 sucks and I can't rely on exfat on all systems I need to 
> interoperate with)
> 
> And let's be realistic here -- the overwhelmingly common threat model 
> here is that there are untrusted files on a correctly-formed filesystem.  
> Bad guys rarely need or care to get root on the system; what they're 
> after requires normal, non-elevated user permissions.
> 
> Prompting users 'are you sure you want to use this device' will turn a 
> "yes" into an automatic reflex.  Not automounting by default will just 
> add another thing to the "things to change on default fedora 
> installations" lists out there (ie right after the "enable freshrpms and 
> install modern video codecs" step), becuase it's a usability nightmare.
> 
> In the "usability vs security" tradeoff, usability/convenience *always* 
> wins unless you're at a place that has armed guards at the door with 
> instructions to shoot first.
> 
>  - Solomon

Then the mount needs to be done in a sandbox, such as a KVM guest or
sandboxed userspace process.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Steve Grubb]

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 
> filesystems are resilient against deliberately malformed filesystems so 
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against 
> adverse input in the real world and so are more likely to contain 
> exploitable bugs
> 
> There are various cases where people do need to make use of uncommon 
> filesystems, but the majority of them aren't related to removable media. 
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
> 
> ought to be enough. So:
> 
> 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?
> 
> Long-term I'd love to see more work put into having FUSE support for 
> these and leaving the in-kernel fs to stuff we know is trustworthy, but 
> that's rather more work.

A while back, I wrote the fsfuzzer specifically to find, in a repeatable way, 
filesystem bugs so they can be fixed:

https://github.com/stevegrubb/fsfuzzer

It does not support all filesystems, but it is easy to add support through 
adding the correct mounter to the scrips. It has found *so* *many* filesystem 
bugs over time.

-Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Solomon Peachy via devel]

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 no restrictions at all.
> >
> 
> So then some kind of configuration to udisks2 to have a similar effect?

And we're right back at square one, with the *overwhelmingly* common case 
of a single-user system whose "admin" is sitting in front of the system.

Of _course_ they want to mount the disk.  It's why they plugged it in, 
and they don't give two hoots if it's a "common filesystem" or not.

(FFS, most of the stuff I personally plug in these days is ext4 or ntfs, 
because fat32 sucks and I can't rely on exfat on all systems I need to 
interoperate with)

And let's be realistic here -- the overwhelmingly common threat model 
here is that there are untrusted files on a correctly-formed filesystem.  
Bad guys rarely need or care to get root on the system; what they're 
after requires normal, non-elevated user permissions.

Prompting users 'are you sure you want to use this device' will turn a 
"yes" into an automatic reflex.  Not automounting by default will just 
add another thing to the "things to change on default fedora 
installations" lists out there (ie right after the "enable freshrpms and 
install modern video codecs" step), becuase it's a usability nightmare.

In the "usability vs security" tradeoff, usability/convenience *always* 
wins unless you're at a place that has armed guards at the door with 
instructions to shoot first.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Neal Gompa]

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 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 would be to disable automounting while the screen is
> >> locked.
> >>
> >>> Long-term I'd love to see more work put into having FUSE support for
> >>> these and leaving the in-kernel fs to stuff we know is trustworthy, but
> >>> that's rather more work.
> >>
> >> Fedora moved in the opposite direction (from gvfs to unprivileged
> >> mounting via udisks2 IIRC).
> >>
> >
> > 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
>
> That's approaching it from the wrong angle, IMHO. It's not that you
> don't want to be able to mount these filesytems at all, it's that you
> don't want let any random unprivileged user do so.
>
> 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 no restrictions at all.
>

So then some kind of configuration to udisks2 to have a similar effect?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Eric Sandeen]

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 process be for disabling it
for people who need this functionality?


Maybe a first step would be to disable automounting while the screen is
locked.


Long-term I'd love to see more work put into having FUSE support for
these and leaving the in-kernel fs to stuff we know is trustworthy, but
that's rather more work.


Fedora moved in the opposite direction (from gvfs to unprivileged
mounting via udisks2 IIRC).



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


That's approaching it from the wrong angle, IMHO. It's not that you 
don't want to be able to mount these filesytems at all, it's that you 
don't want let any random unprivileged user do so.


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 no restrictions at all.


-Eric


We could take a similar approach, maybe...?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Eric Sandeen]

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, and it's not automounted without any
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.


Yup, there's the problem. The user will almost always mount it manually, 
so disabling automount seems pointless.



A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.


The UI would have to not mention technical details like the name of the 
filesystem. Also, warning a user that the filesystem is not 
"well-supported" is also not likely to accomplish much. The user plugged 
in the USB stick in order to look at files, and will almost always 
choose to do so if presented with the option. Even if we warn that the 
device may be malicious (which we don't actually know), users will still 
just think about it and decide "probably not, I want to see my files."


The desktop security model assumes the kernel is robust to malformed 
filesystems and removing that assumption is just not workable. This 
development mindset might be prevalent among kernel developers, but it's 
not acceptable for desktop users.  Filesystems that are not designed to 
be robust to untrusted input should be disabled outright and not 
supported at all. I'm not sure how practical this actually is, though, 
because I think it would probably entail disabling common filesystems 
(ext4? xfs? btrfs?) in addition to uncommon filesystems. Starting with 
disabling uncommon filesystems is better than nothing, though.


mount is a privileged operation in the kernel; when system configuration 
works around that to allow non-trusted users to initiate a mount, that 
breaks the restrictions that the kernel intentionally put on the ability 
to ingest a stream of untrusted data from a block device.


Filesystems generally *do* care about malformed input, but they do so in 
the context of the security model that the kernel defines.


As an example, XFS goes to great lengths to validate input, and placing 
checksums on every piece of metadata is a big part of that. In the real 
world, this validation catches and handles the vast majority of 
malformed/corrupted input that XFS should expect to see.


Other filesystems have similar validation, with similar assumptions.

But when fuzzers intentionally malform metadata and then fix up the 
checksum to look valid, this is something that would never happen 
organically; it is an intentionally malicious work-around to the 
existing mechanism. But again, mount is supposed to be a privileged 
operation, so if the system administrator decides to mount the USB drive 
they found in the parking lot, that's on them, and not a security issue. 
They are root, after all.


Once you let any random user do this, working around the kernel's 
privilege checks, it's a different scenario, and it exposes the system 
to risks that were not part of the original threat model.


I wholeheartedly support any effort to restrict (by default) 
auto-mounting to a smaller set of filesystems that could reasonably be 
expected to be found on removable media (isofs, fat, exfat ...) and shut 
off all the rest to limit the attack surface here. This issue and the 
associated CVEs that get raised have been consuming an inordinate amount 
of time from a very limited set of filesystem developers.


-Eric
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

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

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Matthew Garrett]

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 in a 
filesystem used by Windows is massively unlikely to be present in Linux. 
If your goal is to compromise a Linux device then the attack surface 
available to you (right now) is everything that's present in Linux. For 
removable devices I'd argue that anything other than exfat and vfat are 
probably uncommon, but could be convinced that ext4 and xfs made sense 
as well (and maybe ntfs since I assume some people do want to transfer 
data on USB hard drives)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Demi Marie Obenour]

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 use of it, and it's not automounted without any
>> explanation, they are most likely to just click for it to be mounted,
>> or to even issue an explicit 'mount', defeating the whole protection.
> 
> Yup, there's the problem. The user will almost always mount it 
> manually, so disabling automount seems pointless.
> 
>> A more reasonable UI would be to display a pop-up that says "Device
>> ASDF uses file system AmigaFS 1982 which is not well supported. See
>> https://some.link/ for details. Do you want to a) mount once, b) not
>> mount, c) mount this fs type always?". This would require some work
>> in DE.
> 
> The UI would have to not mention technical details like the name of the 
> filesystem. Also, warning a user that the filesystem is not 
> "well-supported" is also not likely to accomplish much. The user 
> plugged in the USB stick in order to look at files, and will almost 
> always choose to do so if presented with the option. Even if we warn 
> that the device may be malicious (which we don't actually know), users 
> will still just think about it and decide "probably not, I want to see 
> my files."
> 
> The desktop security model assumes the kernel is robust to malformed 
> filesystems and removing that assumption is just not workable. This 
> development mindset might be prevalent among kernel developers, but 
> it's not acceptable for desktop users.  Filesystems that are not 
> designed to be robust to untrusted input should be disabled outright 
> and not supported at all. I'm not sure how practical this actually is, 
> though, because I think it would probably entail disabling common 
> filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems. 
> Starting with disabling uncommon filesystems is better than nothing, 
> though.
> 
> Michael

A much better solution is:

1. Do not mount automatically.  The user might have intended to operate
   on the drive at the block level, such as to create or validate boot
   media.  Instead, defer mounting until the user looks at the contents
   of the filesystem.

2. Perform the mount in a **sandboxed** userspace process or even a
   virtual machine.  This is what Chromium OS does and is the only
   solution that is decently secure.

There are all sorts of other problems that need to be addressed as well,
such as ensuring that only fuzzed and hardened USB drivers are used.
But the mounting restrictions are the first step.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Matthew Garrett]

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 is that if you install a module you need for a static 
mount, you open yourself up to attack via automounts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Neal Gompa]

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 it
> > for people who need this functionality?
>
> Maybe a first step would be to disable automounting while the screen is
> locked.
>
> > Long-term I'd love to see more work put into having FUSE support for
> > these and leaving the in-kernel fs to stuff we know is trustworthy, but
> > that's rather more work.
>
> Fedora moved in the opposite direction (from gvfs to unprivileged
> mounting via udisks2 IIRC).
>

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

We could take a similar approach, maybe...?

openSUSE discussed this back in 2019:
https://lists.opensuse.org/archives/list/fact...@lists.opensuse.org/thread/NCNVFI53B4OSD3E2BVW5QY5MYKMYLH7G/#NCNVFI53B4OSD3E2BVW5QY5MYKMYLH7G




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Florian Weimer]

* 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 would be to disable automounting while the screen is
locked.

> Long-term I'd love to see more work put into having FUSE support for 
> these and leaving the in-kernel fs to stuff we know is trustworthy, but 
> that's rather more work.

Fedora moved in the opposite direction (from gvfs to unprivileged
mounting via udisks2 IIRC).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Michael Catanzaro]

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
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.


Yup, there's the problem. The user will almost always mount it 
manually, so disabling automount seems pointless.



A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.


The UI would have to not mention technical details like the name of the 
filesystem. Also, warning a user that the filesystem is not 
"well-supported" is also not likely to accomplish much. The user 
plugged in the USB stick in order to look at files, and will almost 
always choose to do so if presented with the option. Even if we warn 
that the device may be malicious (which we don't actually know), users 
will still just think about it and decide "probably not, I want to see 
my files."


The desktop security model assumes the kernel is robust to malformed 
filesystems and removing that assumption is just not workable. This 
development mindset might be prevalent among kernel developers, but 
it's not acceptable for desktop users.  Filesystems that are not 
designed to be robust to untrusted input should be disabled outright 
and not supported at all. I'm not sure how practical this actually is, 
though, because I think it would probably entail disabling common 
filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems. 
Starting with disabling uncommon filesystems is better than nothing, 
though.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Zbigniew Jędrzejewski-Szmek]

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 
> filesystems are resilient against deliberately malformed filesystems so 
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against 
> adverse input in the real world and so are more likely to contain 
> exploitable bugs
> 
> There are various cases where people do need to make use of uncommon 
> filesystems, but the majority of them aren't related to removable media. 
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
> 
> ought to be enough. So:
> 
> a) Does this seem like a good idea?

In general, yes. I think the issue can be summed up as:

if you allow an attacker to plug in and automount a USB with an
arbitrary file system, it's almost certain that they will be able to
make the kernel to undefined behaviour. If the list of filesystem
types is limited to the best-supported file system types, there is a
reasonable chance that the attack will fail. By limiting the list
of fs types, we pragmatically make the attack much harder.

FWIW, systemd merged a patch to do something similar in a different
context: https://github.com/systemd/systemd/commit/80ce8580f5.

> b) If so, is dealing with it via udev rules the right approach? This way 
> seems desktop-agnostic

The udev-based approach would work, and is something that could be
used right now. Nevertheless, it's not very user friendly. Some users
will want to override the list, and with the udev-rule-based approach
this is doable but not very convenient.

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
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.

A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.

> c) Where should it ship, and what should the process be for disabling it 
> for people who need this functionality?

> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"

Since those rules are for udisks, I think they should be part of the
udisks package.

If this is done, it'd be much better to make the rule configurable.
So maybe something like this:
SUBSYSTEM=="block", ACTION!="remove", 
PROGRAM="/usr/libexec/fstype-automount-policy", RESULT=="?*", 
ENV{UDISKS_AUTO}="$result"

And the program /usr/libexec/fstype-automount-handline would
have a built-in list, but also look for /etc/kernel/fstype-automount.conf
that would include lists like AUTOMOUNT_FSTYPE_ALLOW=
and AUTOMOUNT_FSTYPE_DISALLOW=.

We could then reuse this machinery in other places, not just udisks.
Obiously this is a very rought draft, but I think it should be extensible
and configurable.

> Long-term I'd love to see more work put into having FUSE support for 
> these and leaving the in-kernel fs to stuff we know is trustworthy, but 
> that's rather more work.

Yep.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[Richard W.M. Jones]

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 
> filesystems are resilient against deliberately malformed filesystems so 
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against 
> adverse input in the real world and so are more likely to contain 
> exploitable bugs
> 
> There are various cases where people do need to make use of uncommon 
> filesystems, but the majority of them aren't related to removable media. 
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
> 
> ought to be enough. So:
> 
> 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?
> 
> Long-term I'd love to see more work put into having FUSE support for 
> these and leaving the in-kernel fs to stuff we know is trustworthy, but 
> that's rather more work.

Well, libguestfs is a thing.

Are any filesystems really trusted?

I do take your point though that some kernel-supported filesystems are
hardly ever used and you should probably need to take special steps to
expose them to your kernel.  At least Fedora no longer enables the BBC
Micro filesystem, last widely used in the 1980s.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Restricting automounting of uncommon filesystems?

[drago01]

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 resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"
>
> ought to be enough. So:
>
> 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?
>
> Long-term I'd love to see more work put into having FUSE support for
> these and leaving the in-kernel fs to stuff we know is trustworthy, but
> that's rather more work.


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)


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.
> org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-
> infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Restricting automounting of uncommon filesystems?

[Matthew Garrett]

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 mostly not proactively looking for bugs there
3) Uncommonly used filesystems are less likely to be tested against 
adverse input in the real world and so are more likely to contain 
exploitable bugs

There are various cases where people do need to make use of uncommon 
filesystems, but the majority of them aren't related to removable media. 
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
shouldn't be automounted, which means something like:

SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
# repeat as necessary for anything else that shouldn't be automounted
LABEL="udisks_insecure_fs_end"

ought to be enough. So:

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?

Long-term I'd love to see more work put into having FUSE support for 
these and leaving the in-kernel fs to stuff we know is trustworthy, but 
that's rather more work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue