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: <20153.24986.33414.602337@quad.stoffel.home>
Date:	Tue, 8 Nov 2011 12:06:34 -0500
From:	"John Stoffel" <john@...ffel.org>
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

>>>>> "Linus" == Linus Torvalds <torvalds@...ux-foundation.org> writes:

Linus> On Mon, Nov 7, 2011 at 12:47 PM, H. Peter Anvin <hpa@...or.com> wrote:
>> 
>> You didn't really get my point.  There are global nodes which are
>> dynamic, and more importantly the *set* changes across the system life.
>>  A global policy option is a lot easier to deal with for the vast
>> majority of users who don't need fine grain control.

Linus> I want *one* global policy that the kernel would actually know about:
Linus> is the user physically at the machine right now.

Linus> Sadly, I don't think the kernel has any good way to figure that out
Linus> automatically.

Linus> Because quite frankly, a lot of the /proc files should be "root or
Linus> desktop user". If you control the hardware, you should damn well be
Linus> able to see the interrupt counts in order to do bug reports etc
Linus> without having to 'sudo' or similar.

Linus> I realize that pam & co could give us this info, or we could just add
Linus> a new capability flag, but I think this is something where the kernel
Linus> really could just do the RightThing(tm) automatically, and screw the
Linus> crazy login managers, odd policies (I really don't believe that adding
Linus> magic selinux rules actually improves security all that much, because
Linus> it's too painful and too hard to know for any normal user).

Linus> The person in front of the hardware really *is* fundamentally special.

Except when they're my kids and I don't want them to shutdown or
suspend the box when they login/logout.   For example, I work on my
desktop at night, and after school, they just login to the same box as
their own account, do their thing, etc.  Then at night after they're
in bed, I use the same machine.  But something they've rebooted it, or
whatever.  A pain.  

Linus> Right now all the distros do magic things with the audio device
Linus> because they know the person in front of the machine is
Linus> special. But all those things are ad-hoc per device, and never
Linus> cover things like random /proc files etc.

It's really hard to know who's sitting there.  And what about
multi-seat setups?  
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ