proc: force dcache drop on unauthorized access

Historically /proc/slabinfo has 0444 permissions and is accessible to the world. slabinfo contains rather private information related both to the kernel and userspace tasks. Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack. Some examples of what can be learned by reading/watching for /proc/slabinfo entries:

Quoted 7 lines · Vasiliy Kulikov

Historically /proc/slabinfo has 0444 permissions and is accessible to the world. slabinfo contains rather private information related both to the kernel and userspace tasks. Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack. Some examples of what can be learned by reading/watching for /proc/slabinfo entries:

...

Since this file is controversy point, probably its permissions might be configurable via setup option?

Historically /proc/slabinfo has 0444 permissions and is accessible to the world. slabinfo contains rather private information related both to the kernel and userspace tasks. Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack. Some examples of what can be learned by reading/watching for /proc/slabinfo entries:

1) dentry (and different *inode*) number might reveal other processes fs activity. The number of dentry "active objects" doesn't strictly show file count opened/touched by a process, however, there is a good correlation between them. The patch "proc: force dcache drop on unauthorized access" relies on the privacy of dentry count.

2) different inode entries might reveal the same information as (1), but these are more fine granted counters. If a filesystem is mounted in a private mount point (or even a private namespace) and fs type differs from other mounted fs types, fs activity in this mount point/namespace is revealed. If there is a single ecryptfs mount point, the whole fs activity of a single user is revealed. Number of files in ecryptfs mount point is a private information per se.

3) fuse_* reveals number of files / fs activity of a user in a user private mount point. It is approx. the same severity as ecryptfs infoleak in (2).

4) sysfs_dir_cache similar to (2) reveals devices' addition/removal, which can be otherwise hidden by "chmod 0700 /sys/". With 0444 slabinfo the precise number of sysfs files is known to the world.

5) buffer_head might reveal some kernel activity. With other information leaks an attacker might identify what specific kernel routines generate buffer_head activity.

6) *kmalloc* infoleaks are very situational. Attacker should watch for the specific kmalloc size entry and filter the noise related to the unrelated kernel activity. If an attacker has relatively silent victim system, he might get rather precise counters.

Additional information sources might significantly increase the slabinfo infoleak benefits. E.g. if an attacker knows that the processes activity on the system is very low (only core daemons like syslog and cron), he may run setxid binaries / trigger local daemon activity / trigger network services activity / await sporadic cron jobs activity / etc. and get rather precise counters for fs and network activity of these privileged tasks, which is unknown otherwise.

Also hiding slabinfo is a one step to complicate exploitation of kernel heap overflows (and possibly, other bugs). The related discussion:

http://thread.gmane.org/gmane.linux.kernel/1108378

World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Signed-off-by Vasiliy Kulikov <[email protected]>

---
 mm/slab.c |    3 ++-
 mm/slub.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

--

mm/slab.c +2 -1

index 6d90a09..560ffd0 100644
@@ -4584,7 +4584,8 @@ static const struct file_operations proc_slabstats_operations = {
 
 static int __init slab_proc_init(void)
 {
-	proc_create("slabinfo",S_IWUSR|S_IRUGO,NULL,&proc_slabinfo_operations);
+	proc_create("slabinfo", S_IWUSR | S_IRUSR, NULL,
+		    &proc_slabinfo_operations);
 #ifdef CONFIG_DEBUG_SLAB_LEAK
 	proc_create("slab_allocators", 0, NULL, &proc_slabstats_operations);
 #endif

mm/slub.c +1 -1

index 9f662d7..f440fc7 100644
@@ -5257,7 +5257,7 @@ static const struct file_operations proc_slabinfo_operations = {
 
 static int __init slab_proc_init(void)
 {
-	proc_create("slabinfo", S_IRUGO, NULL, &proc_slabinfo_operations);
+	proc_create("slabinfo", S_IRUSR, NULL, &proc_slabinfo_operations);
 	return 0;
 }
 module_init(slab_proc_init);

Quoted 3 lines

World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Please tell if anybody has complains about the restriction - whether it forces someone besides kernel developers to do "chmod/chgrp". But if someone want to debug the kernel, it shouldn't significantly influence on common users, especially it shouldn't create security issues.

Quoted 8 lines · Vasiliy Kulikov

Quoted 3 lines

World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Please tell if anybody has complains about the restriction - whether it forces someone besides kernel developers to do "chmod/chgrp". But if someone want to debug the kernel, it shouldn't significantly influence on common users, especially it shouldn't create security issues.

Ubuntu ships today with a /etc/init/mounted-proc.conf that does:

	chmod 0400 "${MOUNTPOINT}"/slabinfo

After cursing Kees's name a few times, I commented it out and it hasn't bothered me again.

I expect that the folks that really care about this (and their distros) will probably have a similar mechanism. I guess the sword cuts both ways in this case: it obviously _works_ to have the distros do it, but it was a one-time inconvenience for me to override that.

In other words, I dunno. If we do this in the kernel, can we at least do something like CONFIG_INSECURE to both track these kinds of things and make it easy to get them out of a developer's way?

Hi Dave,

Quoted 10 lines · Dave Hansen

Quoted 8 lines · Vasiliy Kulikov

Quoted 3 lines

World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Please tell if anybody has complains about the restriction - whether it forces someone besides kernel developers to do "chmod/chgrp". But if someone want to debug the kernel, it shouldn't significantly influence on common users, especially it shouldn't create security issues.

Quoted 6 lines

Ubuntu ships today with a /etc/init/mounted-proc.conf that does:

	chmod 0400 "${MOUNTPOINT}"/slabinfo

After cursing Kees's name a few times, I commented it out and it hasn't bothered me again.

Another way is chgrp slabinfo to some "admin" group which are privileged in this sense and add your user to this group. But please, sane and secure defaults!

Quoted 8 lines

I expect that the folks that really care about this (and their distros) will probably have a similar mechanism. I guess the sword cuts both ways in this case: it obviously _works_ to have the distros do it, but it was a one-time inconvenience for me to override that.

In other words, I dunno. If we do this in the kernel, can we at least do something like CONFIG_INSECURE to both track these kinds of things and make it easy to get them out of a developer's way?

What do you think about adding your user to the slabinfo's group or chmod it - quite the opposite Ubuntu currently does? I think it is more generic (e.g. you may chmod 0444 to allow all users to get debug information or just 0440 and chgrp admin to allow only trusted users to do it) and your local policy doesn't touch the kernel.

Thanks,

Signature · 2 lines

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Quoted 3 lines

In other words, I dunno. If we do this in the kernel, can we at least do something like CONFIG_INSECURE to both track these kinds of things and make it easy to get them out of a developer's way?

What do you think about adding your user to the slabinfo's group or chmod it - quite the opposite Ubuntu currently does? I think it is more generic (e.g. you may chmod 0444 to allow all users to get debug information or just 0440 and chgrp admin to allow only trusted users to do it) and your local policy doesn't touch the kernel.

mm/slab.c static const struct file_operations proc_slabstats_operations = { · line 4590

Quoted 9 lines · Vasiliy Kulikov

mm/slab.c +2 -1

@@ -4584,7 +4584,8 @@ static const struct file_operations proc_slabstats_operations = {
 
 static int __init slab_proc_init(void)
 {
-       proc_create("slabinfo",S_IWUSR|S_IRUGO,NULL,&proc_slabinfo_operations);
+       proc_create("slabinfo", S_IWUSR | S_IRUSR, NULL,
+                   &proc_slabinfo_operations);
 #ifdef CONFIG_DEBUG_SLAB_LEAK
        proc_create("slab_allocators", 0, NULL, &proc_sla 

If you respin this, please don't muck with the whitespace.

Otherwise,
I'm fine with this. Distros are already starting to do this anyway in userspace.

Reviewed-by Dave Hansen <[email protected]>

Historically /proc/slabinfo has 0444 permissions and is accessible to the world. slabinfo contains rather private information related both to the kernel and userspace tasks. Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack. Some examples of what can be learned by reading/watching for /proc/slabinfo entries:
...
World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Signed-off-by Vasiliy Kulikov <[email protected]>

Quoted 11 lines · Vasiliy Kulikov

Historically /proc/slabinfo has 0444 permissions and is accessible to the world. slabinfo contains rather private information related both to the kernel and userspace tasks. Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack. Some examples of what can be learned by reading/watching for /proc/slabinfo entries:
...
World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits. For most users 0444 slabinfo is an unreasonable attack vector.

Quoted 1 line

Signed-off-by Vasiliy Kulikov <[email protected]>

Haven't had any mass complaints about the 0400 in Ubuntu (sorry Dave!), so I'm obviously for it.

Reviewed-by Kees Cook <[email protected]>

Quoted 1 line

Reviewed-by Kees Cook <[email protected]>

Looks like the members of the previous slabinfo discussion don't object against the patch now and it got two other Reviewed-by responses. Can you merge it as-is or should I probably convince someone else?

Quoted 13 lines · Vasiliy Kulikov

Quoted 12 lines

Historically /proc/slabinfo has 0444 permissions and is accessible to the world.  slabinfo contains rather private information related both to the kernel and userspace tasks.  Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack.  Some examples of what can be learned by reading/watching for /proc/slabinfo entries:
...
World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits.  For most users 0444 slabinfo is an unreasonable attack vector.

Signed-off-by Vasiliy Kulikov <[email protected]>

Quoted 4 lines

Haven't had any mass complaints about the 0400 in Ubuntu (sorry Dave!), so I'm obviously for it.

Reviewed-by Kees Cook <[email protected]>

Looks like the members of the previous slabinfo discussion don't object against the patch now and it got two other Reviewed-by responses.  Can you merge it as-is or should I probably convince someone else?

Quoted 14 lines · Kees Cook

Quoted 13 lines · Vasiliy Kulikov

Quoted 12 lines

Historically /proc/slabinfo has 0444 permissions and is accessible to the world.  slabinfo contains rather private information related both to the kernel and userspace tasks.  Depending on the situation, it might reveal either private information per se or information useful to make another targeted attack.  Some examples of what can be learned by reading/watching for /proc/slabinfo entries:
...
World readable slabinfo simplifies kernel developers' job of debugging kernel bugs (e.g. memleaks), but I believe it does more harm than benefits.  For most users 0444 slabinfo is an unreasonable attack vector.

Signed-off-by Vasiliy Kulikov <[email protected]>

Quoted 3 lines · Vasiliy Kulikov

Quoted 3 lines

Haven't had any mass complaints about the 0400 in Ubuntu (sorry Dave!), so I'm obviously for it.

Quoted 5 lines

Quoted 1 line

Reviewed-by Kees Cook <[email protected]>

Looks like the members of the previous slabinfo discussion don't object against the patch now and it got two other Reviewed-by responses.  Can you merge it as-is or should I probably convince someone else?

We discussed this in March (google for 'Make /proc/slabinfo 0400')

and
concluded that it's not worth it doesn't really protect from anything

and causes harm to developers.

Quoted 2 lines

and
concluded that it's not worth it doesn't really protect from anything

Closing only slabinfo doesn't add any significant protection against kernel heap exploits per se, no objections here.

But as said in the desciption, the reason for this patch is not protecting against exploitation heap bugs.  It is a source of infoleaks of kernel and userspace activity, which should be forbidden to non-root users.

Quoted 1 line

and causes harm to developers.

One note: only to _kernel_ developers.  It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

Quoted 9 lines · Vasiliy Kulikov

Quoted 2 lines

and
concluded that it's not worth it doesn't really protect from anything

Closing only slabinfo doesn't add any significant protection against kernel heap exploits per se, no objections here.

But as said in the desciption, the reason for this patch is not protecting against exploitation heap bugs.  It is a source of infoleaks of kernel and userspace activity, which should be forbidden to non-root users.

Last time we discussed this, the 'extra protection' didn't seem to be significant enough to justify disabling an useful kernel debugging interface by default.

What's different about the patch now?

Quoted 4 lines

Quoted 1 line

and causes harm to developers.

One note: only to _kernel_ developers.  It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

It's pretty much _the_ interface for debugging kernel memory leaks in production systems and we ask users for it along with /proc/meminfo when debugging many memory management related issues. When we temporarily dropped /proc/slabinfo with the introduction of SLUB, people complained pretty loudly.

I'd be willing to consider this patch if it's a config option that's not enabled by default; otherwise you need to find someone else to merge the patch. You can add some nasty warnings to the Kconfig text to scare the users into enabling it. ;-)

Quoted 11 lines · Pekka Enberg

Quoted 9 lines · Vasiliy Kulikov

Quoted 2 lines

and
concluded that it's not worth it doesn't really protect from anything

Closing only slabinfo doesn't add any significant protection against kernel heap exploits per se, no objections here.

But as said in the desciption, the reason for this patch is not protecting against exploitation heap bugs.  It is a source of infoleaks of kernel and userspace activity, which should be forbidden to non-root users.

Quoted 5 lines

Last time we discussed this, the 'extra protection' didn't seem to be significant enough to justify disabling an useful kernel debugging interface by default.

What's different about the patch now?

The exploitation you're talking about is an exploitation of kernel heap bugs.  Dan's previous "make slabinfo 0400" patch tried to complicate attacker's life by hiding information about how many free object are left in the slab.  With this information an attacker may compute how he should spray the slab to position slab object to increase his chances of overwriting specific memory areas - pointers, etc.

I don't speak about how much/whether closing slabinfo complicates this task, though.  My idea is orthogonal to the Dan's idea.  I claim that with 0444 slabinfo any user may get information about in-system activity that he shouldn't learn.  In short, one may learn precisely when other user reads directory contents, opens files, how much files there are in the specific _private_ directory, how much files _private_ ecryptfs or fuse mount point contains, etc.  This breaks user's assumption that the number of files in a private directory is a private information. There are a bit more thoughts in the patch description.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

and causes harm to developers.

One note: only to _kernel_ developers.  It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

Quoted 5 lines

It's pretty much _the_ interface for debugging kernel memory leaks in production systems and we ask users for it along with /proc/meminfo when debugging many memory management related issues. When we temporarily dropped /proc/slabinfo with the introduction of SLUB, people complained pretty loudly.

Could you point to the discussion, please?  I cannot find the patch for 0400 slabinfo even in the linux-history repository.

Quoted 4 lines

I'd be willing to consider this patch if it's a config option that's not enabled by default; otherwise you need to find someone else to merge the patch. You can add some nasty warnings to the Kconfig text to scare the users into enabling it. ;-)

How do you see this CONFIG_ option?  CONFIG_PROCFS_COMPAT_MODES (or _PERMS), defaults to Y?  If we find more procfs files with dangerous permissions, we may move it under "ifndef CONFIG_PROCFS_COMPAT_PERMS".

Quoted 9 lines

Quoted 1 line

What's different about the patch now?

The exploitation you're talking about is an exploitation of kernel heap bugs.  Dan's previous "make slabinfo 0400" patch tried to complicate attacker's life by hiding information about how many free object are left in the slab.  With this information an attacker may compute how he should spray the slab to position slab object to increase his chances of overwriting specific memory areas - pointers, etc.

Quoted 9 lines

I don't speak about how much/whether closing slabinfo complicates this task, though.  My idea is orthogonal to the Dan's idea.  I claim that with 0444 slabinfo any user may get information about in-system activity that he shouldn't learn.  In short, one may learn precisely when other user reads directory contents, opens files, how much files there are in the specific _private_ directory, how much files _private_ ecryptfs or fuse mount point contains, etc.  This breaks user's assumption that the number of files in a private directory is a private information. There are a bit more thoughts in the patch description.

Yes, I read your patch description and I think it's convincing enough to warrant a config option but not changing the default.

However, if the encryptfs and infoleaks really are serious enough to hide /proc/slabinfo, I think you should consider switching over to kmalloc() instead of kmem_cache_alloc() to make sure nobody can gain access to the information.

Quoted 9 lines

Quoted 8 lines

Quoted 2 lines

One note: only to _kernel_ developers.  It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

It's pretty much _the_ interface for debugging kernel memory leaks in production systems and we ask users for it along with /proc/meminfo when debugging many memory management related issues. When we temporarily dropped /proc/slabinfo with the introduction of SLUB, people complained pretty loudly.

Quoted 2 lines

Could you point to the discussion, please?  I cannot find the patch for 0400 slabinfo even in the linux-history repository.

We dropped the whole file for SLUB:

http://lwn.net/Articles/263337/

[ I didn't find the original discussion that motivated the above
patch but it should be somewhere in LKML archives around that time. ]

Making it root-only will have pretty much the same kind of out-of-the-box behavior.

Quoted 5 lines

Quoted 4 lines

I'd be willing to consider this patch if it's a config option that's not enabled by default; otherwise you need to find someone else to merge the patch. You can add some nasty warnings to the Kconfig text to scare the users into enabling it. ;-)

Quoted 3 lines

How do you see this CONFIG_ option?  CONFIG_PROCFS_COMPAT_MODES (or _PERMS), defaults to Y?  If we find more procfs files with dangerous permissions, we may move it under "ifndef CONFIG_PROCFS_COMPAT_PERMS".

I guess CONFIG_RESTRICT_PROCFS type of thing makes most sense since the problem is not only about SLAB. If you want to make it slab-only config option, I'm fine with that too.

Please note that you need to restrict sysfs files for SLUB as well.

Quoted 4 lines

However, if the encryptfs and infoleaks really are serious enough to hide /proc/slabinfo, I think you should consider switching over to kmalloc() instead of kmem_cache_alloc() to make sure nobody can gain access to the information.

kmalloc() is still visible in slabinfo as kmalloc-128 or so.

Quoted 5 lines · Vasiliy Kulikov

Quoted 4 lines

However, if the encryptfs and infoleaks really are serious enough to hide /proc/slabinfo, I think you should consider switching over to kmalloc() instead of kmem_cache_alloc() to make sure nobody can gain access to the information.

Quoted 1 line

kmalloc() is still visible in slabinfo as kmalloc-128 or so.

Yes, but there's no way for users to know where the allocations came from if you mix them up with other kmalloc-128 call-sites. That way the number of private files will stay private to the user, no? Doesn't that give you even better protection against the infoleak?

Quoted 6 lines

Quoted 1 line

kmalloc() is still visible in slabinfo as kmalloc-128 or so.

Yes, but there's no way for users to know where the allocations came from if you mix them up with other kmalloc-128 call-sites. That way the number of private files will stay private to the user, no? Doesn't that give you even better protection against the infoleak?

No, what it gives us is an obscurity, not a protection. I'm sure it highly depends on the specific situation whether an attacker is able to identify whether the call is from e.g. ecryptfs or from VFS. Also the correlation between the number in slabinfo and the real private actions still exists.

IMHO a restriction of access to slab statistics is reasonable in a hardened environment. Make it dependent on CONFIG_SECURITY or some such thing?

Quoted 3 lines · Christoph Lameter

IMHO a restriction of access to slab statistics is reasonable in a hardened environment. Make it dependent on CONFIG_SECURITY or some such thing?

Probably need to invent a separate Kconfig variable - CONFIG_SECURITY is probably a way-too-big hammer for this nail. I can see lots of systems that want to enable that, but won't want to tighten access to slab.

Quoted 6 lines · On Mon, 19 Sep 2011, [email protected] wrote:

Quoted 3 lines · Christoph Lameter

IMHO a restriction of access to slab statistics is reasonable in a hardened environment. Make it dependent on CONFIG_SECURITY or some such thing?

Quoted 3 lines

Probably need to invent a separate Kconfig variable - CONFIG_SECURITY is probably a way-too-big hammer for this nail. I can see lots of systems that want to enable that, but won't want to tighten access to slab.

There is already CONFIG_SECURITY_DMESG_RESTRICT. Generalize that setting to include all sorts of other kernel statistics?

Quoted 4 lines

Yes, but there's no way for users to know where the allocations came from if you mix them up with other kmalloc-128 call-sites. That way the number of private files will stay private to the user, no? Doesn't that give you even better protection against the infoleak?

No, what it gives us is an obscurity, not a protection.  I'm sure it highly depends on the specific situation whether an attacker is able to identify whether the call is from e.g. ecryptfs or from VFS.  Also the correlation between the number in slabinfo and the real private actions still exists.

Quoted 10 lines · Vasiliy Kulikov

Quoted 4 lines

Yes, but there's no way for users to know where the allocations came from if you mix them up with other kmalloc-128 call-sites. That way the number of private files will stay private to the user, no? Doesn't that give you even better protection against the infoleak?

No, what it gives us is an obscurity, not a protection.  I'm sure it highly depends on the specific situation whether an attacker is able to identify whether the call is from e.g. ecryptfs or from VFS.  Also the correlation between the number in slabinfo and the real private actions still exists.

How is the attacker able to identify that we kmalloc()'d from ecryptfs or VFS based on non-root /proc/slabinfo when the slab allocator itself does not have that sort of information if you mix up the allocations?

Isn't this
much stronger protection especially if you combine that with /proc/slabinfo restriction?

Quoted 3 lines

Isn't this
much stronger protection especially if you combine that with /proc/slabinfo restriction?

I don't see any reason to change allocators if we close slabinfo.

Quoted 5 lines · Vasiliy Kulikov

Quoted 3 lines

Isn't this
much stronger protection especially if you combine that with /proc/slabinfo restriction?

I don't see any reason to change allocators if we close slabinfo.

OK, so what about /proc/meminfo, sysfs, 'perf kmem', and other kernel interfaces through which you can get direct or indirect information about kernel memory allocations?

Oh, we also have perf...  Given these are separate interfaces, I think slab oriented restriction makes more sense.

So, now we have:

/proc/slabinfo
/sys/kernel/slab
/proc/meminfo
'perf kmem' - not sure what specific files should be guarded

Is there another way to get directly or indirectly the information about slabs?

OK, so what about /proc/meminfo, sysfs, 'perf kmem', and other kernel interfaces through which you can get direct or indirect information about kernel memory allocations?

Also, quite frankly, your argument that /proc/slabinfo is so important for kernel debugging is bogus. Every time I've complained about the fact that the thing is useless AND ACTIVELY MISLEADING because it mixes up all the slabs (so big numbers for "vm_area_struct" might actually be about some other slab entirely, and *has* been, to the point of people wasting time), the answer has been "whatever".

You can't have it both ways just to argue for the status quo.

Considering how useless /proc/slabinfo actually is today - exactly because of the misleading mixing - I suspect the right thing to do is to make it root-only.

Having some aggregate number in /proc/meminfo would probably be fine.

And yes, we probably should avoid giving page-level granularity in /proc/meminfo too. Do it in megabytes instead. None of the information there is really relevant at a page level, everybody just wants rough aggregates.

Quoted 6 lines

Having some aggregate number in /proc/meminfo would probably be fine.

And yes, we probably should avoid giving page-level granularity in /proc/meminfo too. Do it in megabytes instead. None of the information there is really relevant at a page level, everybody just wants rough aggregates.

We have this in /proc/meminfo:

Slab:              20012 kB

Or did you mean something even more specific?

Well, sure. I was actually planning to rip out SLUB merging completely because it makes /proc/slabinfo so useless but never got around doing that.

How is the attacker able to identify that we kmalloc()'d from ecryptfs or VFS based on non-root /proc/slabinfo when the slab allocator itself does not have that sort of information if you mix up the allocations? Isn't this much stronger protection especially if you combine that with /proc/slabinfo restriction?

Quoted 5 lines

How is the attacker able to identify that we kmalloc()'d from ecryptfs or VFS based on non-root /proc/slabinfo when the slab allocator itself does not have that sort of information if you mix up the allocations? Isn't this much stronger protection especially if you combine that with /proc/slabinfo restriction?

Mixing it up just adds noise.  It makes the attack somewhat more difficult, but it still leaves open the possibility that the attacker can filter out the noise somehow.

One note: only to _kernel_ developers. It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

Quoted 3 lines · Vasiliy Kulikov

One note: only to _kernel_ developers. It means it is a strictly debugging feature, which shouldn't be enabled in the production systems.

Until somebody at vendor support says "What does 'cat /proc/slabinfo' say?"

Anybody who thinks that debugging tools should be totally disabled on "production" systems probably hasn't spent enough time actually running production systems.

Anybody who thinks that debugging tools should be totally disabled on "production" systems probably hasn't spent enough time actually running production systems.

Agreed - far better it is simply set root only.

Sorry, I've poorly worded my statement. Of course I mean root-only slabinfo, not totally disable it.

Linus, Alan, Kees, and Dave are about to simply restrict slabinfo (and probably similar interfaces) to root. Pekka is OK too.

Christoph and Valdis are about to create new CONFIG_ option to be able to restrict the access to slabinfo/etc., but with old relaxed permissions.

The patch "proc: fix races against execve() of /proc/PID/fd**" is still a partial fix for a setxid problem. link(2) is a yet another way to identify whether a specific fd is opened by a privileged process. By calling link(2) against /proc/PID/fd/* an attacker may identify whether the fd number is valid for PID by analysing link(2) return code.

Both getattr() and link() can be used by the attacker iff the dentry is present in the dcache. In this case ->lookup() is not called and the only way to check ptrace permissions is either operation handler or ->revalidate(). The easiest solution to prevent any unauthorized access to /proc/PID/fd*/ files is to force the dentry drop on each unauthorized access attempt.

If an attacker keeps opened fd of /proc/PID/fd/ and dcache contains a specific dentry for some /proc/PID/fd/XXX, any future attemp to use the dentry by the attacker would lead to the dentry drop as a result of a failed ptrace check in ->revalidate(). Then the attacker cannot spawn a dentry for the specific fd number because of ptrace check in ->lookup().

The dentry drop can be still observed by an attacker by analysing information from /proc/slabinfo, which is addressed in the successive patch.