Re: Removing FUSE would theoretically make a system more secure?

[Gregor Best]

On Sun, Jan 28, 2018 at 06:11:51PM +0100, who one wrote:
> Hello, 
> 
> "> And what are you defending against?"
> 
> there was/is a great guy that investigated the security of the BSDs, reported 
> a few bugs too: 
> 
> https://www.youtube.com/watch?v=rRg2vuwF1hY=youtu.be=1522
> 
> that lead to ex.: 
> 
> https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig
> [...]

By that logic, you've just disabled a piece of code that someone (Helg)
is actively working on and that has security issues fixed. What makes
you so sure there are no deadly bugs in, say, the FAT code? Or drivers
for rare-ish network cards? Or the ~120k lines of code that make up the
driver for Intel graphics cards?

Of course running less code means less of an attack surface. Just make
sure you're actually improving security if that's your goal, not just
diddling around on the fringes of your system and feeling secure because
Fuse is disabled while you're running Chrome which has access to your
~/.ssh/id_ed25519 or ~/.bitcoin/wallet.dat.

> [...]
> So would the mentioned method, by removing the "grep -i fuse
> /sys/conf/GENERIC" and doing re-compile would "disable FUSE"? 
> [...]

If would. But as already mentioned by other people, the barriers to Fuse
are relatively high (You need code exec as root to fiddle with
/dev/fuse0), while code you're actually running may have more of an
impact on your security situation.

-- 
Gregor

Re: Removing FUSE would theoretically make a system more secure?

[who one]

Hello, 

"> And what are you defending against?"

there was/is a great guy that investigated the security of the BSDs, reported a 
few bugs too: 

https://www.youtube.com/watch?v=rRg2vuwF1hY=youtu.be=1522

that lead to ex.: 

https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/017_fuse.patch.sig

So would the mentioned method, by removing the "grep -i fuse /sys/conf/GENERIC" 
and doing re-compile would "disable FUSE"? 

Thanks for the syspatch/relinking hint, I forgot about them if I touch the 
kernel!

Thanks!


> Sent: Sunday, January 28, 2018 at 5:15 AM
> From: mar...@martinbrandenburg.com
> To: misc@openbsd.org, whoonet...@mail.com
> Subject: Re: Removing FUSE would theoretically make a system more secure?
>
> > afaik if I would remove the lines that contains "FUSE" and "fuse" from 
> > /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be 
> > no more FUSE support in my kernel after reboot.
> >
> > If so, would this step help to make my system more secure? Ex.: from a 
> > future FUSE related security issue? 
> >
> > just asking theoretically, since I don't use FUSE related stuff, so 
> > thinking of that is unneeded. 
> >
> > or it would just create an unsupported kernel which didn't had any tests 
> > regarding the missing fuse and maybe cause bigger issues and security 
> > issues vs. if I wouldn't touched it? 
> 
> I daresay that removing FUSE support will make you invulnerable to any
> kind of bug in FUSE.  jca has already given you an outline of the
> reasons to believe such a bug, if it exists, is rather unlikely to be
> exploitable.
> 
> You had better consider what you're giving up when you make this change.
> You won't be able to use FUSE.  You won't be able to use syspatch.  I'm
> not sure how it affects kernel relinking.  You'll have to build your
> kernels yourself on all architectures you run for each release and every
> kernel-related erratum.  You'll have to maintain your changes.  You
> can't just say "I'm not sure" as I just did.  You'll have to take
> responsibility for the possibility that running a non-standard
> configuration may introduce bugs.
> 
> And what are you defending against?  Somebody has to get root or a way
> to mount filesystems without root.  We'll assume he's got a way to mount
> filesystems without root, because if he had a way to get root, he
> wouldn't need bother with anything else.  Then he's got to have his FUSE
> exploit which gives him root.  Since he probably doesn't have an account
> on your system, he's got to have a third exploit to start running code
> to begin with.
> 
> Defense in depth is good, but this isn't worth the effort on your part.
> 
> Your security need only be good enough to require an attacker spend more
> than he's willing to spend.
> 
> Martin
> 
> 

Re: Removing FUSE would theoretically make a system more secure?

[martin]

> afaik if I would remove the lines that contains "FUSE" and "fuse" from 
> /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be 
> no more FUSE support in my kernel after reboot.
>
> If so, would this step help to make my system more secure? Ex.: from a future 
> FUSE related security issue? 
>
> just asking theoretically, since I don't use FUSE related stuff, so thinking 
> of that is unneeded. 
>
> or it would just create an unsupported kernel which didn't had any tests 
> regarding the missing fuse and maybe cause bigger issues and security issues 
> vs. if I wouldn't touched it? 

I daresay that removing FUSE support will make you invulnerable to any
kind of bug in FUSE.  jca has already given you an outline of the
reasons to believe such a bug, if it exists, is rather unlikely to be
exploitable.

You had better consider what you're giving up when you make this change.
You won't be able to use FUSE.  You won't be able to use syspatch.  I'm
not sure how it affects kernel relinking.  You'll have to build your
kernels yourself on all architectures you run for each release and every
kernel-related erratum.  You'll have to maintain your changes.  You
can't just say "I'm not sure" as I just did.  You'll have to take
responsibility for the possibility that running a non-standard
configuration may introduce bugs.

And what are you defending against?  Somebody has to get root or a way
to mount filesystems without root.  We'll assume he's got a way to mount
filesystems without root, because if he had a way to get root, he
wouldn't need bother with anything else.  Then he's got to have his FUSE
exploit which gives him root.  Since he probably doesn't have an account
on your system, he's got to have a third exploit to start running code
to begin with.

Defense in depth is good, but this isn't worth the effort on your part.

Your security need only be good enough to require an attacker spend more
than he's willing to spend.

Martin

Re: Removing FUSE would theoretically make a system more secure?

[Jeremie Courreges-Anglas]

On Sat, Jan 27 2018, "who one"  wrote:
> Hello, 
>
> afaik if I would remove the lines that contains "FUSE" and "fuse" from 
> /sys/conf/GENERIC and re-compile the kernel, that would mean, there will be 
> no more FUSE support in my kernel after reboot.
>
> If so, would this step help to make my system more secure? Ex.: from a future 
> FUSE related security issue? 

Not really.  Right now you need to be root to mount a filesystem,
this includes fuse filesystems*. This restriction would make it hard for
a rogue unprivileged user to exploit bugs in fuse kernel code.

Previously, a sysctl setting was available to allow user mounts
(including fuse mounts), but this setting has been removed.  You also
needed to be root to set that flag.

> just asking theoretically, since I don't use FUSE related stuff, so thinking 
> of that is unneeded. 
>
> or it would just create an unsupported kernel which didn't had any tests 
> regarding the missing fuse and maybe cause bigger issues and security issues 
> vs. if I wouldn't touched it? 

Different means unsupported. ;)

* this is not very convenient.  Also I don't know if our implementation
  is affected, but running a fuse filesystem with the allow_other option
  could bring security issues... See
  https://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/html/security.html
-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Removing FUSE would theoretically make a system more secure?

[who one]

Hello, 

afaik if I would remove the lines that contains "FUSE" and "fuse" from 
/sys/conf/GENERIC and re-compile the kernel, that would mean, there will be no 
more FUSE support in my kernel after reboot.

If so, would this step help to make my system more secure? Ex.: from a future 
FUSE related security issue? 

just asking theoretically, since I don't use FUSE related stuff, so thinking of 
that is unneeded. 

or it would just create an unsupported kernel which didn't had any tests 
regarding the missing fuse and maybe cause bigger issues and security issues 
vs. if I wouldn't touched it? 

Many thanks!