--- ...translators_set_up_by_untrusted_users.mdwn | 115 +++++++++++++++++- 1 file changed, 114 insertions(+), 1 deletion(-)
diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn index ad0187e3..af48d736 100644 --- a/open_issues/translators_set_up_by_untrusted_users.mdwn +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2013, 2014, 2026 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -11,6 +11,119 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] +Blindly running someone else's unverified code or shell scripts is +almost always a bad idea. The same is true of running translators set +by someone else. Running untrusted translators by default would +enable malicious behavior, and the Hurd needs more work to adequately +resolve this problem. Please note that regular Hurd users implicitly +trust and run translators in `/dev/` and `/servers/` by default (eg: +`/servers/socket/2`, `/dev/rumpdisk`, `/dev/console`, etc.). + +<!-- + +I'm not sure if I want to keep this paragraph. braunr briefly --> +<!-- mentioned this in the context of hurd's lack of persistency. But --> +<!-- it might be useful to mention when you run access another uses' --> +<!-- translator, that translator runs with the permission and UID of --> +<!-- whoever own the inode. + +Another interesting question to answer is, "who runs a passive +translator?" When `bob` follows `jordan`s symlink, whose permission --> +<!--does the symlink use? In this case it would run using jordan's --> +<!--permission, because jordon ownes the inode where the command is --> +<!--stored in the filesystem. --> + +Here's an example that shows why running untrusted users translators +is a bad idea. Suppose that friends Fred and Bob store photos on a +shared a Hurd server, and once a year, Fred shares his photos with +friends via a semi-automated email. Fred likes Bob's photos so much +that he decides to copy them to his collection. + + fred@hurd:~/ $ mkdir bobs-photos + fred@hurd:~/ $ sudo cp -r /home/bob/photos ./bobs-photos/ + +What Fred doesn't know, is that Bob has put a special translator on +`/home/bob/photos` that uses a crafty [[netfs|hurd/libnetfs]] +translator to dynamically create a recursive directory structure of +the same two photos: + + /home/bob/photos + | + --- dog.png + | + --- dog2.png + | + --- .hidden # this directory and others like it are + | # on demand populated by netfs. + | + --- cat.png # is actually dog.png + | + --- horse.png # is actually dog2.png + | + --- .hidden + | + --- unicorn.png # dog.png + | + --- rainbow.png # dog2.png + | + --- .hidden + | + --- # repeats 10 more times with more unique + # filenames + +Fred's has just created multiple copies of the same files! Fred might +notice that the copy command takes a little long, and he might not +even notice the problem until he generates the yearly email, when he +will finally notice multiple copies of the same dog photo! Bob that +odd rascal! + +While this is a silly and light heart example, a malicious user Karen +(who doesn't even have a `$HOME` directory) could set a translator in +the world-writeable `/tmp/` directory that silently changes the +current working directory to `/home/`. If Fred ran `$ rm -r /tmp/*` +he would inadvertently delete files in own `$HOME`, but if he used `# +rm -r /tmp` he would unknowingly delete all photos on the machine! +Karen, or any other attacker, could write a nasty translator that +never returns from `RPCs`, hoards RAM, and/or runs a pointless and +endless CPU intensive tasks (for example, bitcoin mining). Luckily +glibc does protect itself from rogue translators. For example, it has +timeouts on translators that won't answer the interrupt RPC. + +There are a few proposed solutions. + +### Never Run Translators set by others + +This is the simplest and possibly the most effective solution (which +is what Linux's FUSE does). The Hurd provides `O_NOTRANS` to disable +running translators set by others. This policy would protect `joshua` +from malicious users' rogue translators. However, this policy can be +too rigid. For example, it is desirable to run `/dev/null` and `ftpfs` +as non-root, which is the current default. Perhaps `O_NOTRANS` should +be something like `O_TRUSTED_TRANS` meaning "only run trusted users' +translators". Perhaps the root user can create a `trusted` group, and +users only follow translators if they are a member of the `trusted` +group. + +However, it should also be possible for users to explicitly enable +running translators by users that they trust or to never run +translators set by others (except those in `/dev/` or `/servers/`). +Perhaps these settings could be set in an environment variable. + +### Fix our existing reauth mechanism + +This problem and a potential solution was discussed in our [[email +list|https://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html]]. + +### Do not accept reauth from untrusted translators + +Not accepting reauth from untrusted translators would also fix +the privilege escalations (similar to the proposed modified reauth +mechanism, only more invasive). + + +This problem is related to +[[open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection]] +and [[open_issues/trust_the_behavior_of_translators]]. # IRC, freenode, #hurd, 2011-07-17 -- 2.51.0
