On Fri, Jul 31, 2009 at 09:03:37AM +0200, Cédric Dufour - Idiap Research Institute wrote:
> Hello VServer maintainers,
> I'm sorry to bump the subject up again, but we'd really need some
> feedback about the modifications we need to have NFS work with our
> multi-100k$ filers (and which may certainly benefit other NFS/CIFS/AFS
> users in the future); Please see 70~ lines patch attached in previous
> message in this ML thread (
> http://list.linux-vserver.org/archive?mss:2708:200907:pfggfkbbnhmhomeamdng
> ).
> Are those modifications plain stupid or does they seem acceptable?
I've seen the patch, and my gut feeling tells me that
it isn't the best idea to put network filesystems in
the same category than procfs and devpts (which have
their very own security checks, btw)
if you want me to take a closer look at it right now,
feel free to hire me as consultant, I'm sure I can
make some room for this ...
best,
Herbert
> Thank you very much for your insight.
> Have a good day,
> Cédric Dufour @ Idiap Research Institute
> On 24/07/09 10:55, Cédric Dufour - Idiap Research Institute wrote:
> > Finally, here is the least "invasive" modification - from a security
> > point of view - we could come up with (see attached patch). NFS
> > junctions now work as expected. As for security, we'd definitively need
> > some feedback ;-)
> >
> > Cheers
> >
> > Cédric Dufour @ Idiap Research Institute
> >
> >
> >
> > On 23/07/09 18:46, Cédric Dufour - Idiap Research Institute wrote:
> >
> >> [STRIPPED]
> >>
> >> On 23/07/09 15:22, Cédric Dufour - Idiap Research Institute wrote:
> >>
> >>> Hello again,
> >>>
> >>> After some research in the kernel tree, it seems that the
> >>> 'vfs_kern_mount' function gets called directly:
> >>> - to handle CIFS DFS (in function 'cifs_dfs_do_refmount')
> >>> - to handle AFS automounts (in function 'afs_mntpt_do_automount')
> >>> - to handle NFS "junctions" (in function 'nfs_follow_mountpoint')
> >>> In other words, for all file systems that require some in-kernel
> >>> "sub-mounting", and which should NOT be blocked in anyway (provided the
> >>> "root" mount point has been successfully mounted, see below)
> >>>
> >>> Indirectly (via 'do_kern_mount'), to performs actual "out-of-kernel"
> >>> mount requests.
> >>>
> >>> Indirectly (via 'kern_mount_data', with a MS_KERNMOUNT flag that is used
> >>> subsequently by 'selinux_sb_kern_mount' to relax security) for:
> >>> - '/proc' sub-system
> >>> - IPC sub-system
> >>>
> >>> This suggests that the capability checks achieved in 'vfs_kern_mount'
> >>> would - maybe - be better fitted and adapted in the calling
> >>> functions/contexts:
> >>> - in 'do_new_mount' for actual file systems mount (where we find an
> >>> existing 'capable('CAP_SYS_ADMIN')' test ;-) )
> >>> - ... I don't know about /proc and IPC ... (but aren't handling the
> >>> former with the 'PROC_SUPER_MAGIC' flag ?)
> >>>
> >>> What do you think ?
> >>>
> >>> Cédric Dufour @ Idiap Research Institute
> >>>
> >>>
> >>>
> >>> On 23/07/09 13:19, Cédric Dufour - Idiap Research Institute wrote:
> >>>
> >>>
> >>>> Hello,
> >>>>
> >>>> We are currently putting our new NetApp ONTAP GX system into
> >>>> production. From the NFS point of view, the particularity of this
> >>>> product is that it allows to "assemble" multiple volumes within a
> >>>> "unified" namespace, using so-called "junctions", and access this
> >>>> "unified" namespace with a (apparently) single mount operation.
> >>>>
> >>>> Now, when using VServer - even from the host point of view - only the
> >>>> root user is able to "roam" through the mounted hierarchy (as separate
> >>>> volumes get automatically mounted in the background and appear in
> >>>> '/proc/mounts'). Non-root user get a "Operation not permitted" message
> >>>> as soon as they try to go pass the initially mounted volume.
> >>>>
> >>>> This problem seem absolutely similar to what was discussed in this
> >>>> thread: http://www.paul.sladen.org/vserver/archives/200709/0046.html
> >>>>
> >>>> We have verified that removing the VServer-added checks in the
> >>>> 'vfs_kern_mount' function (in '<kernel-source>/fs/super.c') "solves"
> >>>> the problem (we used the latest 2.6.30.2 vanilla kernel and
> >>>> 2.3.0.36.14pre4 VServer patches to perform this verification).
> >>>>
> >>>> Now to the questions:
> >>>>
> >>>> 1. What is the security impact of removing those checks (iow. is it a
> >>>> "MUST NOT!!!" or a "well... that's being overkill anyway" ) ?
> >>>>
> >>>> 2. Can we imagine to perform those checks slightly differently, in
> >>>> order to allow non-root users to use such "joined" NFS exports, both
> >>>> from the host and guests (since we're no kernel gurus, we don't know
> >>>> which function/capability to start looking for) ?
> >>>>
> >>>> Thank you very much for your help and time.
> >>>>
> >>>> Cheers
> >>>>
> >>>> --
> >>>>
> >>>> Cédric Dufour @ Idiap Research Institute
> >>>>
> >>>> Phone: +41 27 721 77 40
> >>>> Fax: +41 27 721 77 12
> >>>> Mail: Idiap Research Institute
> >>>> Case postale 592
> >>>> Centre du Parc
> >>>> 1920 Martigny (VS)
> >>>> Suisse (Switzerland)
> >>>> Web: www.idiap.ch <http://www.idiap.ch>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
Received on Sat Aug 1 16:45:48 2009