[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EB82F08.8060209@zytor.com>
Date: Mon, 07 Nov 2011 11:18:32 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Vasiliy Kulikov <segoon@...nwall.com>
CC: 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,
Linus Torvalds <torvalds@...ux-foundation.org>,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] proc: restrict access to /proc/interrupts
On 11/07/2011 11:01 AM, Vasiliy Kulikov wrote:
>
> What's wrong with old good DAC? You can create a group "sysinfo", do
> "chown sysinfo /proc/interrupts", and add the permitted users to the
> group. If you need to give different access levels to different interrupts,
> you need another /proc/interrupts design, it does nothing with DAC vs. LSM.
>
I would like to propose that we add a mount option to procfs, and
possibly sysfs, called, say, admingrp. These kinds of files then get
restricted to the admingrp (defaulting to gid 0 if no admingrp is
provided). Historically on Unix there has been a group of people
(usually "adm", but sometimes "log") who are allowed to read (but not
write) the log files, which also contains potentially sensitive information.
The current Linux trend seems to be do instead force those users to
become root constantly, which is *not* helping the situation.
-hpa
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
