i'd love to help, but i'm not that familiar with all this stuff... sorry! bertl... i think this is a call to your experience! :) grtzzz Rik Bobbaers -- http://harry.enzoverder.be linux/unix/system/network/security/hardware/DR admin > 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? > > 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> >>>>> >>>>> >>>>> >>>> >>>> >