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

[ebiederm@xmission.com (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