linux-kernel - Re: [PATCH] Make /proc/slabinfo 0400

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:	Fri, 4 Mar 2011 08:52:04 +0200
From:	Pekka Enberg <penberg@...nel.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Dan Rosenberg <drosenberg@...curity.com>,
	Matt Mackall <mpm@...enic.com>, cl@...ux-foundation.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] Make /proc/slabinfo 0400

On Mar 3, 2011, at 5:30 PM, Dan Rosenberg wrote:
>> I appreciate your input on this, you've made very reasonable points.
>> I'm just not convinced that those few real users are being substantially
>> inconvenienced, even if there's only a small benefit for the larger
>> population of users who are at risk for attacks.  Perhaps others could
>> contribute their opinions to the discussion.

On Fri, Mar 4, 2011 at 2:50 AM, Theodore Tso <tytso@....edu> wrote:
> Being able to monitor /proc/slabinfo is incredibly useful for finding various
> kernel problems.  We can see if some part of the kernel is out of balance,
> and we can also find memory leaks.   I once saved a school system's Linux
> deployment because their systems were crashing once a week, and becoming
> progressively more unreliable before they crashed, and the school board
> was about to pull the plug.

Indeed. However, I'm not sure we need to expose the number of _active
objects_ to non-CAP_ADMIN users (which could be set to zeros if you
don't have sufficient privileges). Memory leaks can be detected from
the total number of objects anyway, no?

On Fri, Mar 4, 2011 at 2:50 AM, Theodore Tso <tytso@....edu> wrote:
> I wonder if there is some other change we could make to the slab allocator
> that would make it harder for exploit writers without having to protect the
> /proc/slabinfo file.  For example, could we randomly select different free
> objects in a page instead of filling them in sequentially?

We can do something like that if we can live with the performance costs.
--
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/