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

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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 10 Aug 2014 11:11:56 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jörg Otte <jrg.otte@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [proc:] 3.16.0-10436-g9138475: access denied to /proc/1540/task/1540/net/dev

On Sun, Aug 10, 2014 at 10:25 AM, Jörg Otte <jrg.otte@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/