Re: [PATCH] fuse: allow CAP_SYS_ADMIN in root userns to access allow_other mount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 18, 2022 at 4:26 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Wed, 18 May 2022 at 13:22, Christian Brauner <brauner@xxxxxxxxxx> wrote:
> >
> > On Tue, May 17, 2022 at 12:50:32PM -0400, Dave Marchevsky wrote:
>
> > > Sorry to ressurect this old thread. My proposed alternate approach of "special
> > > ioctl to grant exception to descendant userns check" proved unnecessarily
> > > complex: ioctls also go through fuse_allow_current_process check, so a special
> > > carve-out would be necessary for in both ioctl and fuse_permission check in
> > > order to make it possible for non-descendant-userns user to opt in to exception.
> > >
> > > How about a version of this patch with CAP_DAC_READ_SEARCH check? This way
> > > there's more of a clear opt-in vs CAP_SYS_ADMIN.
> >
> > I still think this isn't needed given that especially for the use-cases
> > listed here you have a workable userspace solution to this problem.

Unfortunately such userspace solution isn't that great in practice.
It's both very cumbersome to implement and integrate into existing
profiling solutions and causes undesired inefficiencies when
processing (typically for stack trace symbolization) lots of profiled
processes.

> >
> > If the CAP_SYS_ADMIN/CAP_DAC_READ_SEARCH check were really just about
> > giving a privileged task access then it'd be fine imho. But given that
> > this means the privileged task is open to a DoS attack it seems we're
> > building a trap into the fuse code.

Running under root presumably means that the application knows what
it's doing (and it can do a lot of dangerous and harmful things
outside of FUSE already), so why should there be any more opt in for
it to access file contents? CAP_SYS_ADMIN can do pretty much anything
in the system, it seems a bit asymmetric to have extra FUSE-specific
restrictions for it.

> >
> > The setns() model has the advantage that this forces the task to assume
> > the correct privileges and also serves as an explicit opt-in. Just my 2
> > cents here.
>
> Fully agreed.  Using CAP_DAC_READ_SEARCH instead of CAP_SYS_ADMIN
> doesn't make this any better, since root has all caps including
> CAP_DAC_READ_SEARCH.
>
> Thanks,
> Miklos



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux