linux-kernel - Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

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]

Message-ID: <CA+55aFxFNaRuTx-0vx+RhrkavrcNDiDh5jxcRyWPy8-QZHGD9A@mail.gmail.com>
Date:	Mon, 7 Nov 2011 15:07:42 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Vasiliy Kulikov <segoon@...nwall.com>,
	Eric Paris <eparis@...isplace.org>,
	kernel-hardening@...ts.openwall.com, Valdis.Kletnieks@...edu,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-security-module@...r.kernel.org
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

On Mon, Nov 7, 2011 at 1:35 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> I was going to say "let's just have the login manager add a group to the
> desktop user's permission set" but then I realized that this would be
> really bad because of setgid files.
>
> Which exposes a real problem with chgrp and setgid files overall.

No, the problem is more fundamental, and this is simply not something
you should try to solve with traditional unix permissions.

Why? Because the problem really isn't about opening the file. The
problem is about any access: once you've opened the file, you *still*
must not be able to read the data from it if you have logged out and
somebody else has logged in. Think opening the microphone (which you
*should* be able to do) and just keeping it open until the next user
logs in.

Or do the same with /proc/interrupts.

Your "oops, you can get your group permissions back with a setgrp
binary" example case is just a trivial case of the much bigger
picture: access has to be actively *revoked*.

Sure, you can still do it in user space, but it gets really hacky
really quickly. You need to do some magic random permission logic,
*and* you need to add revoke support for every single file that ends
up being affected.

It's just a broken model.

So I really think it would be much better to just have a per-user flag
that says "this user has access to the physical machine", and that
flag gets tested not only on open but on reads etc of the appropriate
/proc files. It really is a kind of "temporary admin privileges",
where "admin" is much weaker than root, but does mean that you have
access to whatever directly attached devices
(sound/video/keyboard/whatever), and that you can examine machine
state (ie a lot of the "sensitive" /proc stuff, like slabinfo and
interrupts and /proc/status etc).

Trying to fake it with groups is wrong. It's much *better* to fake it
with POSIX ACL's (which don't have the setgrp issue you mention), but
that still ends up being problematic wrt revoke etc.

Faking it with posix acl's is what the /dev/audio stuff tends to do.
It's better than nothing, but it really isn't wonderful - because it's
really not just about audio. And revoke doesn't work universally.

Practically speaking, I suspect we are going to be at the mercy of
distros getting things like this right, with these kinds of user-level
hacks. But I think it's sad.

               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/