On Sat, Oct 6, 2018 at 4:10 AM Aleksa Sarai wrote:
> On 2018-10-05, Jann Horn wrote:
> > > What if we took rename_lock (call it nd->r_seq) at the start of the
> > > resolution, and then only tried the __d_path-style check
> > >
> > > if (read_seqretry(&rename_lock, nd->r_seq) ||
> > > rea
On Sat, Oct 6, 2018 at 10:56 PM Florian Weimer wrote:
>
> * Aleksa Sarai:
>
> > On 2018-10-01, Andy Lutomirski wrote:
> >> >>> Currently most container runtimes try to do this resolution in
> >> >>> userspace[1], causing many potential race conditions. In addition, the
> >> >>> "obvious" alternat
* Aleksa Sarai:
> On 2018-10-01, Andy Lutomirski wrote:
>> >>> Currently most container runtimes try to do this resolution in
>> >>> userspace[1], causing many potential race conditions. In addition, the
>> >>> "obvious" alternative (actually performing a {ch,pivot_}root(2))
>> >>> requires a for
On 2018-10-05, Jann Horn wrote:
> > What if we took rename_lock (call it nd->r_seq) at the start of the
> > resolution, and then only tried the __d_path-style check
> >
> > if (read_seqretry(&rename_lock, nd->r_seq) ||
> > read_seqretry(&mount_lock, nd->m_seq))
> > /* do the __d_
On Fri, Oct 5, 2018 at 5:07 PM Aleksa Sarai wrote:
> On 2018-10-04, Jann Horn wrote:
> > On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > > > Something else concurrently moves /A/
On 2018-10-04, Jann Horn wrote:
> On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > On 2018-09-29, Jann Horn wrote:
> > > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > > Something else concurrently moves /A/B/C to /A/C. This can result in
> > > the following:
> > >
> >
On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> >
> > 1. You start the path walk and reach /A/B/C.
On Fri, Oct 05, 2018 at 02:26:11AM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> >
> > 1. You start the path walk and re
On Tue, Oct 02, 2018 at 02:18:33AM +1000, Aleksa Sarai wrote:
> On 2018-10-01, Jann Horn wrote:
> > > If this is an issue for AT_THIS_ROOT, I believe this might also be an
> > > issue for AT_BENEATH since they are effectively both using the same
> > > nd->root trick (so you could similarly trick A
On 2018-09-29, Jann Horn wrote:
> You attempt to open "C/../../etc/passwd" under the root "/A/B".
> Something else concurrently moves /A/B/C to /A/C. This can result in
> the following:
>
> 1. You start the path walk and reach /A/B/C.
> 2. The other process moves /A/B/C to /A/C. Your path walk is
On Tue, Oct 2, 2018 at 12:32 AM Aleksa Sarai wrote:
>
> On 2018-10-01, Andy Lutomirski wrote:
> > >>> Currently most container runtimes try to do this resolution in
> > >>> userspace[1], causing many potential race conditions. In addition, the
> > >>> "obvious" alternative (actually performing a
On 2018-10-01, Andy Lutomirski wrote:
> >>> Currently most container runtimes try to do this resolution in
> >>> userspace[1], causing many potential race conditions. In addition, the
> >>> "obvious" alternative (actually performing a {ch,pivot_}root(2))
> >>> requires a fork+exec which is *very*
On 2018-10-01, Jann Horn wrote:
> > If this is an issue for AT_THIS_ROOT, I believe this might also be an
> > issue for AT_BENEATH since they are effectively both using the same
> > nd->root trick (so you could similarly trick AT_BENEATH to not error
> > out). So we'd need to figure out how to sol
>>> Currently most container runtimes try to do this resolution in
>>> userspace[1], causing many potential race conditions. In addition, the
>>> "obvious" alternative (actually performing a {ch,pivot_}root(2))
>>> requires a fork+exec which is *very* costly if necessary for every
>>> filesystem
On Sat, Sep 29, 2018 at 06:35:17PM +0200, Jann Horn wrote:
> +cc linux-api; please keep them in CC for future versions of the patch
>
> On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
> > The primary motivation for the need for this flag is container runtimes
> > which have to interact with m
On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under
On Mon, Oct 01, 2018 at 01:29:16PM +0200, Jann Horn wrote:
> On Mon, Oct 1, 2018 at 12:42 PM Christian Brauner
> wrote:
> > On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > The problem is what happens if a folder you are walking through
On Mon, Oct 1, 2018 at 12:42 PM Christian Brauner wrote:
> On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> > On 2018-09-29, Jann Horn wrote:
> > > The problem is what happens if a folder you are walking through is
> > > concurrently moved out of the chroot. Consider the following
On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under
On Mon, Oct 1, 2018 at 7:44 AM Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> >
> > You attempt to open "C/../../etc/passwd" under the root "/
On 2018-09-29, Andy Lutomirski wrote:
> >> On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
> >> The primary motivation for the need for this flag is container runtimes
> >> which have to interact with malicious root filesystems in the host
> >> namespaces. One of the first requirements for a
On 2018-09-29, Jann Horn wrote:
> The problem is what happens if a folder you are walking through is
> concurrently moved out of the chroot. Consider the following scenario:
>
> You attempt to open "C/../../etc/passwd" under the root "/A/B".
> Something else concurrently moves /A/B/C to /A/C. Thi
> On Sep 29, 2018, at 9:35 AM, Jann Horn wrote:
>
> +cc linux-api; please keep them in CC for future versions of the patch
>
>> On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
>> The primary motivation for the need for this flag is container runtimes
>> which have to interact with malici
+cc linux-api; please keep them in CC for future versions of the patch
On Sat, Sep 29, 2018 at 4:29 PM Aleksa Sarai wrote:
> The primary motivation for the need for this flag is container runtimes
> which have to interact with malicious root filesystems in the host
> namespaces. One of the first
The primary motivation for the need for this flag is container runtimes
which have to interact with malicious root filesystems in the host
namespaces. One of the first requirements for a container runtime to be
secure against a malicious rootfs is that they correctly scope symlinks
(that is, they s
25 matches
Mail list logo
