Re: [vserver] NetApp filers and NFS junctions: Operation not permitted [RFC]

From: Cédric Dufour - Idiap Research Institute <cedric.dufour_at_idiap.ch>
Date: Sun 02 Aug 2009 - 01:05:48 BST
Message-ID: <4A74D85C.6090906@idiap.ch>

Hello Herbert,

Thank you for your feedback. I'll talk to my hierarchy about your
proposition.

Best regards

Cédric

Herbert Poetzl wrote:
> 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 Sun Aug 2 01:06:13 2009

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sun 02 Aug 2009 - 01:06:15 BST by hypermail 2.1.8