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>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
Received on Fri Jul 31 09:28:40 2009