diff for duplicates of <20110919161837.GA2232@albatros> diff --git a/a/1.txt b/N1/1.txt index 6b8f069..80fe022 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,19 +2,19 @@ On Mon, Sep 19, 2011 at 19:11 +0300, Pekka Enberg wrote: > >> 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 +> > 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 +> > 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 +> > 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 +> > 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 +> > 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. > @@ -29,7 +29,7 @@ On Mon, Sep 19, 2011 at 19:11 +0300, Pekka Enberg wrote: kmalloc() is still visible in slabinfo as kmalloc-128 or so. -> >> > One note: only to _kernel_ developers. It means it is a strictly +> >> > 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 @@ -38,7 +38,7 @@ kmalloc() is still visible in slabinfo as kmalloc-128 or so. > >> 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 +> > 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: @@ -60,8 +60,8 @@ Ah, I've misunderstood you. > >> 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, +> > 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 @@ -80,3 +80,10 @@ Thank you for the comments! -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments + +-- +To unsubscribe, send a message with 'unsubscribe linux-mm' in +the body to majordomo@kvack.org. For more info on Linux MM, +see: http://www.linux-mm.org/ . +Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index c6c9a02..7066758 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -31,19 +31,19 @@ "> >> What's different about the patch now?\n" "> >\n" "> > The exploitation you're talking about is an exploitation of kernel heap\n" - "> > bugs. \302\240Dan's previous \"make slabinfo 0400\" patch tried to complicate\n" + "> > bugs. Dan's previous \"make slabinfo 0400\" patch tried to complicate\n" "> > attacker's life by hiding information about how many free object are\n" - "> > left in the slab. \302\240With this information an attacker may compute how he\n" + "> > left in the slab. With this information an attacker may compute how he\n" "> > should spray the slab to position slab object to increase his chances of\n" "> > overwriting specific memory areas - pointers, etc.\n" "> >\n" "> > I don't speak about how much/whether closing slabinfo complicates this\n" - "> > task, though. \302\240My idea is orthogonal to the Dan's idea. \302\240I claim that\n" + "> > task, though. My idea is orthogonal to the Dan's idea. I claim that\n" "> > with 0444 slabinfo any user may get information about in-system activity\n" - "> > that he shouldn't learn. \302\240In short, one may learn precisely when other\n" + "> > that he shouldn't learn. In short, one may learn precisely when other\n" "> > user reads directory contents, opens files, how much files there are in\n" "> > the specific _private_ directory, how much files _private_ ecryptfs or\n" - "> > fuse mount point contains, etc. \302\240This breaks user's assumption that\n" + "> > fuse mount point contains, etc. This breaks user's assumption that\n" "> > the number of files in a private directory is a private information.\n" "> > There are a bit more thoughts in the patch description.\n" "> \n" @@ -58,7 +58,7 @@ "kmalloc() is still visible in slabinfo as kmalloc-128 or so.\n" "\n" "\n" - "> >> > One note: only to _kernel_ developers. \302\240It means it is a strictly\n" + "> >> > One note: only to _kernel_ developers. It means it is a strictly\n" "> >> > debugging feature, which shouldn't be enabled in the production systems.\n" "> >>\n" "> >> It's pretty much _the_ interface for debugging kernel memory leaks in\n" @@ -67,7 +67,7 @@ "> >> temporarily dropped /proc/slabinfo with the introduction of SLUB, people\n" "> >> complained pretty loudly.\n" "> >\n" - "> > Could you point to the discussion, please? \302\240I cannot find the patch for\n" + "> > Could you point to the discussion, please? I cannot find the patch for\n" "> > 0400 slabinfo even in the linux-history repository.\n" "> \n" "> We dropped the whole file for SLUB:\n" @@ -89,8 +89,8 @@ "> >> You can add some nasty warnings to the Kconfig text to scare the users\n" "> >> into enabling it. ;-)\n" "> >\n" - "> > How do you see this CONFIG_ option? \302\240CONFIG_PROCFS_COMPAT_MODES (or _PERMS),\n" - "> > defaults to Y? \302\240If we find more procfs files with dangerous permissions,\n" + "> > How do you see this CONFIG_ option? CONFIG_PROCFS_COMPAT_MODES (or _PERMS),\n" + "> > defaults to Y? If we find more procfs files with dangerous permissions,\n" "> > we may move it under \"ifndef CONFIG_PROCFS_COMPAT_PERMS\".\n" "> \n" "> I guess CONFIG_RESTRICT_PROCFS type of thing makes most sense\n" @@ -108,6 +108,13 @@ "\n" "-- \n" "Vasiliy Kulikov\n" - http://www.openwall.com - bringing security into open computing environments + "http://www.openwall.com - bringing security into open computing environments\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -517aac35e1381c0ff535c2d6b5925a7684638e69b99db6b512ffd089be4ed34e +c6b791567882196c37c8bce00ba890be32238011dff33a3d4f3f64ccbd5a8542
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.