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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 30 Sep 2022 21:28:31 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'Eric W. Biederman'" <>
CC:     Linus Torvalds <>,
        Al Viro <>,
        "" <>,
        "" <>,
        "Serge E. Hallyn" <>
Subject: RE: [CFT][PATCH] proc: Update /proc/net to point at the accessing
 threads network namespace

From: Eric W. Biederman
> Sent: 30 September 2022 17:17
> David Laight <David.Laight@...LAB.COM> writes:
> > From: Eric W. Biederman
> >> Sent: 29 September 2022 23:48
> >>
> >> Since common apparmor policies don't allow access /proc/tgid/task/tid/net
> >> point the code at /proc/tid/net instead.
> >>
> >> Link:
> >> Signed-off-by: "Eric W. Biederman" <>
> >> ---
> >>
> >> I have only compile tested this.  All of the boiler plate is a copy of
> >> /proc/self and /proc/thread-self, so it should work.
> >>
> >> Can David or someone who cares and has access to the limited apparmor
> >> configurations could test this to make certain this works?
> >
> > It works with a minor 'cut & paste' fixup.
> > (Not nested inside a program that changes namespaces.)
> Were there any apparmor problems?  I just want to confirm that is what
> you tested.

I know nothing about apparmor - I just tested that /proc/net
pointed to somewhere that looked right.

> Assuming not this patch looks like it reveals a solution to this
> issue.
> > Although if it is reasonable for /proc/net -> /proc/tid/net
> > why not just make /proc/thread-self -> /proc/tid
> > Then /proc/net can just be thread-self/net
> There are minor differences between the process directories that
> tend to report process wide information and task directories that
> only report some of the same information per-task.  So in general
> thread-self makes much more sense pointing to a per-task directory.
> The hidden /proc/tid/ directories use the per process code to generate
> themselves.  The difference is that they assume the tid is the leading
> thread instead of the other process.  Those directories are all a bit of
> a scrambled mess.  I was suspecting the other day we might be able to
> fix gdb and make them go away entirely in a decade or so.
> So I don't think it makes sense in general to point /proc/thread-self at
> the hidden per /proc/tid/ directories.

Ok - I hadn't actually looked in them.
But if you have a long-term plan to remove them directing /proc/net
thought them might not be such a good idea.

> > I have wondered if the namespace lookup could be done as a 'special'
> > directory lookup for "net" rather that changing everything when the
> > namespace is changed.
> > I can imagine scenarios where a thread needs to keep changing
> > between two namespaces, at the moment I suspect that is rather
> > more expensive than a lookup and changing the reference counts.
> You can always open the net directories once, and then change as
> an open directory will not change between namespaces.

Part of the problem is that changing the net namespace isn't
enough, you also have to remount /sys - which isn't entirely
It might be possibly to mount a network namespace version
of /sys on a different mountpoint - I've not tried very
hard to do that.

> > Notwithstanding the apparmor issues, /proc/net could actuall be
> > a symlink to (say) /proc/net_namespaces/namespace_name with
> > readlink returning the name based on the threads actual namespace.
> There really aren't good names for namespaces at the kernel level.  As
> one of their use cases is to make process migration possible between
> machines.  So any kernel level name would need to be migrated as well.
> So those kernel level names would need a name in another namespace,
> or an extra namespace would have to be created for those names.

Network namespaces do seem to have names.
Although I gave up working out how to change to a named network
namespace from within the kernel (especially in a non-GPL module).

> > FWIW I'm pretty sure there a sequence involving unshare() that
> > can get you out of a chroot - but I've not found it yet.
> Out of a chroot is essentially just:
> 	chdir("/");
>         chroot("/somedir");
>         chdir("../../../../../../../../../../../../../../../..");

A chdir() inside a chroot anchors at the base of the chroot.
fchdir() will get you out if you have an open fd to a directory
outside the chroot.
The 'usual' way out requires a process outside the chroot to
just use mvdir().
But there isn't supposed to be a way to get out.

I can certainly get the /proc symlinks (for a copy of /proc
mounted inside a chroot) to report the full paths for files
that exist inside the chroot.
These should (and do normally) truncate at the chroot base.
(This all happened because a pivot_root() was failing.)


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists