lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 30 Nov 2017 17:11:26 +0800
From:   Ian Kent <raven@...maw.net>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linux Containers <containers@...ts.linux-foundation.org>,
        linux-kernel@...r.kernel.org, Miklos Szeredi <mszeredi@...hat.com>,
        linux-fsdevel@...r.kernel.org,
        Seth Forshee <seth.forshee@...onical.com>
Subject: Re: [PATCH 0/2] userns: automount cleanups

On 30/11/17 13:21, Eric W. Biederman wrote:
> Ian Kent <raven@...maw.net> writes:
> 
>> On 30/11/17 08:01, Eric W. Biederman wrote:
>>>
>>> While reviewing some code I realized that in getting d_automount working
>>> with s_user_ns I had left behind some unnecessary relics of the blind
>>> path I started down.  Here are two patches that remove those relics.
>>>
>>> Unless someone has another preference I will drop them in my userns tree
>>> and merge them that way.
>>
>> I saw the "<etc>->s_user_ns != &init_user_ns" and wondered if that would
>> trigger for automount(8) run entirely with a container (eg. docker)?
> 
> autofs still needs FS_USERNS_MOUNT before you can reach that point.  But
> docker does have a mode ?--userns-remap? where it sets up the containers
> mounts that way.
> 
> I think in principle that should work and be safe.  I don't know how
> robust autofs is against malicious users.  Which is the question to ask
> before actually adding FS_USERNS_MOUNT in struct file_system_type.

automount(8) thinks it is running as uid 0 (which it is in the container)
so this would require a bit of thought since automount(8) doesn't take
special precautions.

The restrictions, in the case of running entirely within a container, are
those of the container itself. For example, if there are no granular
capabilities available then the admin needs to run the container as
privileged in order to be able to mount NFS file systems, which is a
common usage case. 

Ian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ