manual merge

1 files changed, 73 insertions, 0 deletions

diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
index edc92796..97f48bba 100644
--- a/open_issues/translators_set_up_by_untrusted_users.mdwn
+++ b/open_issues/translators_set_up_by_untrusted_users.mdwn
@@ -272,3 +272,76 @@ License|/fdl]]."]]"""]]
       to solve security issues at all
     <antrik> and as braunr already pointed out, this wouldn't help with DoS
       problems
+
+
+# Linux kernel, Symlink/Hardlink Attack
+
+Even though not directly comparable, the issues described at [Symlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection)
+and [Hardlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection)
+do bear some similarity with the issue we're discussing here.
+
+
+# IRC, freenode, #hurd, 2011-08-31
+
+    <antrik> I don't see any problems with following only translators of
+      trusted users
+    <youpi> where to store the list of trusted users?
+    <youpi> is there a way to access the underlying node, which for /dev
+      entries belongs to root?
+    <ArneBab> youpi: why a list of trusted users? Does it not suffice to
+      require /hurd/trust set by root or ourselves?
+    <youpi> ArneBab: just because that's what antrik suggests, so I ask him for
+      more details
+    <ArneBab> ah, ok
+    <antrik> youpi: probably make them members of a group
+    <antrik> of course that doesn't allow normal users to add their own trusted
+      users... but that's not the only limitation of the user-based
+      authentication mechanism, so I wouldn't consider that an extra problem
+    <antrik> ArneBab: we can't set a translator on top of another user's
+      translator in general
+    <antrik> root could, but that's not very flexible...
+    <antrik> the group-based solution seems more useful to me
+    <ArneBab> antrik: why can’t we?
+    <antrik> also note that you can't set passive translators on top of other
+      translators
+    <antrik> ArneBab: because we can only set translators on our own nodes
+    <ArneBab> active ones, too?
+    <antrik> yes
+    <ArneBab> antrik: I always thought I could…
+    <ArneBab> but did not test it
+    <ArneBab> antrik: so I need a subhurd to change nodes which do not belong
+      to me?
+    * ArneBab in that case finally understands why you like subhurds so much:
+        That should be my normal right
+    <antrik> it should be your normal right to change stuff not belonging to
+      you? that's an odd world view :-)
+    <antrik> subhurds don't really have anything to do with it
+    <ArneBab> change it in a way that only I see the changes
+    <antrik> you need local namespaces to allow making local modifications to
+      global resources
+    <youpi> it should be one's normal right to change the view one has of it
+    <antrik> we discussed that once actually I believe...
+    <antrik> err... private namespaces I mean
+
+IRC, freenode, #hurd, 2011-09-10:
+
+    <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of
+      the hurd on mach. One of the arguments is that a file system may be
+      malicious (by DoS its clients with infinitely deep directory
+      hierarchies). Is there an answer to that that does not require programs
+      to be programmed defensively against such possibilities?
+
+IRC, freenode, #hurd, 2011-09-14:
+
+    <antrik> cjuner: regarding malicious filesystems: the answer is to do
+      exactly the same as FUSE on Linux: don't follow translators set up by
+      untrusted users by default
+    <cjuner> antrik, but are legacy programs somehow protected? What about
+      executing `find`? Or is GNU's find somehow protected from that?
+    <antrik> cjuner: I'm talking about a global policy
+    <cjuner> antrik, and who would implement that policy?
+    <antrik> cjuner: either glibc or the parent translators
+
+Continued discussion about [[resource_management_problems/pagers]].