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]

Date:	Mon, 7 Nov 2011 23:21:32 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	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

> 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.

We need minimal revocation stuff. This hasn't changed in years. You can
mostly work around it with SELinux but the underlying problem is that you
need a small controlled subset of revokable devices and objects and a
meaningful way to revoke them.

The latter is hard to do with a simple noddy model because there are
multi-user systems with multiple audio devices, multiple displays and the
like where the mapping is not a simple 'this list of objects is console'
but needs user space to do the work.

> Faking it with posix acl's is what the /dev/audio stuff tends to do.

The audio stuff mostly uses daemons to manage it. A bigger problem is
file system mounts. If you've got an old handle on /dev/cdrom you can
pass it down a socket to a background irritant that just does an eject
every five minutes. Students were doing this in SunOS 4 and I'm sure
still find it funny today.

> 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.

BSD invented revoke but never implemented it universally. It turns out
that this isn't a big problem. Right now we basically only have revoke
for tty devices but we don't need it for that much more. Revoke on disk
files and the like has simply never happened because its not a matter of
revoke being universal so much as universal revoke being universally
pointless.

Alan
--
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/