[proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[Jörg Otte]

My network interface eth0 doesn't come up in 3.16.0-10436-g9138475
I am seeing following "security problem" in dmesg:

audit: type=1400 audit(1407684227.003:28): apparmor="DENIED"
  operation="open" profile="/sbin/dhclient"
  name="/proc/1540/task/1540/net/dev" pid=1540 comm="dhclient"
  requested_mask="r" denied_mask="r" fsuid=0 ouid=0

I think the problem is introduced by the following commits, especially
6ba8ed7:

344470c proc: Point /proc/mounts at /proc/thread-self/mounts instead
of /proc/self/mounts
e813244 proc: Point /proc/net at /proc/thread-self/net instead of /proc/self/net
0097875 proc: Implement /proc/thread-self to point at the directory of
the current thread
6ba8ed7 proc: Have net show up under /proc/<tgid>/task/<tid>

To get eth0 activated I need to MODIFY APPARMOR-CONFIGURATION:

e.g.
# Site-specific additions and overrides for sbin.dhclient.
# For more details, please see /etc/apparmor.d/local/README.
/sbin/dhclient {
  @{PROC}/[0-9]*/task/[0-9]*/net/ r,
  @{PROC}/[0-9]*/task/[0-9]*/net/** r
}

Is this interface change to user space intentional?

Thanks,
Jörg

Re: [proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[Linus Torvalds]

On Sun, Aug 10, 2014 at 10:25 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
> My network interface eth0 doesn't come up in 3.16.0-10436-g9138475
> I am seeing following "security problem" in dmesg:
>
> audit: type=1400 audit(1407684227.003:28): apparmor="DENIED"
>   operation="open" profile="/sbin/dhclient"
>   name="/proc/1540/task/1540/net/dev" pid=1540 comm="dhclient"
>   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>
> I think the problem is introduced by the following commits, especially
> 6ba8ed7:

Ok.  Just to be sure, can you verify by reverting or bisecting exactly
which one breaks for you? I suspect it's commits 344470cac42e and
e81324407269 (commit 6ba8ed79a3cc just adds a "net" entry to the
thread case too, not just the task). Well, only e81324407269 will
matter for *this* case, but the /proc/mounts issue is basically
identical.

Eric, some or all of those need to be reverted, and regardless you
need to stop thinking you can just change things.

I realize that you knew about this possibility, but you now need to
not just realize that "it is possible that this breaks things" to
really stop doing crap like this. If you realize you are changing
semantics or moving files around, you need to go "I must not do that".

This crazy namespace disease of trying to "fix" things by breaking
existing code MUST STOP. I'm growing really tired of this.

It does sound like the problem may be specific to the fact that
apparmor cares about the exact path we're using, and thus what
*should* be harmless changes to the symlink from "current task" to
"current thread" exposes things. Admittedly apparmor is a bit crazy if
so, but I'm guessing your base apparmor config currently special-cases
"/proc/<pid>" but _not_ "/proc/<pid>/task/<pid>"

I'm wondering if we could/should make /proc/mount and /proc/net point
to /proc/<pid> at _least_ when current->namespace ==
current->thread_leader->namespace.

            Linus

Re: [proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[Eric W. Biederman]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sun, Aug 10, 2014 at 10:25 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
>> My network interface eth0 doesn't come up in 3.16.0-10436-g9138475
>> I am seeing following "security problem" in dmesg:
>>
>> audit: type=1400 audit(1407684227.003:28): apparmor="DENIED"
>>   operation="open" profile="/sbin/dhclient"
>>   name="/proc/1540/task/1540/net/dev" pid=1540 comm="dhclient"
>>   requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>>
>> I think the problem is introduced by the following commits, especially
>> 6ba8ed7:
>
> Ok.  Just to be sure, can you verify by reverting or bisecting exactly
> which one breaks for you? I suspect it's commits 344470cac42e and
> e81324407269 (commit 6ba8ed79a3cc just adds a "net" entry to the
> thread case too, not just the task). Well, only e81324407269 will
> matter for *this* case, but the /proc/mounts issue is basically
> identical.
>
> Eric, some or all of those need to be reverted, and regardless you
> need to stop thinking you can just change things.
>
> I realize that you knew about this possibility, but you now need to
> not just realize that "it is possible that this breaks things" to
> really stop doing crap like this. If you realize you are changing
> semantics or moving files around, you need to go "I must not do that".
>
> This crazy namespace disease of trying to "fix" things by breaking
> existing code MUST STOP. I'm growing really tired of this.

My apologies.  I really didn't think it would matter.  Certainly not
matter so much that people have machines that don't boot.  I am making
a note to myself that security policies are crazy and changes to /proc
should take that into account.  Sigh.

It seems clear that 344470cac42e and e81324407269 are causing more
trouble than the small amount of pain they were meant to solve, so let's
just revert them.

That does nothing for the weird multi-threadded apps that access
/proc/net/... and are surprised when it doesn't work.  It just leaves
them in the same shape they are today.

> It does sound like the problem may be specific to the fact that
> apparmor cares about the exact path we're using, and thus what
> *should* be harmless changes to the symlink from "current task" to
> "current thread" exposes things. Admittedly apparmor is a bit crazy if
> so, but I'm guessing your base apparmor config currently special-cases
> "/proc/<pid>" but _not_ "/proc/<pid>/task/<pid>"
>
> I'm wondering if we could/should make /proc/mount and /proc/net point
> to /proc/<pid> at _least_ when current->namespace ==
> current->thread_leader->namespace.

That might work.

Whatever is tried (besides a revert of 344470cac42e and e81324407269) it
looks like it is best left for another merge window.  Otherwise I am
afraid we will be playing whack-a-mole.

Linus would you like me to send pull request with those two changes reverted?

Eric

Re: [proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[Linus Torvalds]

On Sun, Aug 10, 2014 at 1:05 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> Linus would you like me to send pull request with those two changes reverted?

I just did them (delayed it a bit in the hope to get confirmation, but
it looks very straightforward, so since I'll be on airplanes most of
tomorrow..)

             Linus

Re: [proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

[Jörg Otte]

2014-08-11 6:30 GMT+02:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Sun, Aug 10, 2014 at 1:05 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> Linus would you like me to send pull request with those two changes reverted?
>
> I just did them (delayed it a bit in the hope to get confirmation, but
> it looks very straightforward, so since I'll be on airplanes most of
> tomorrow..)
>
>              Linus

OK, Kernel: 3.16.0-10473-gc8d6637 fixes the problem for me.

Thanks,
Jörg