[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] # IRC, freenode, #hurd, 2011-07-17 Reventlov: this is the so-called "firmlink issue" -- though AFAIK it doesn't actually apply to firmlinks ;-) the problem is that any user can in theory create and set up a special translator, which will redirect to another directory, without any indication that it's a link but this doesn't supersede the file system permissions, does it ? as a result, if someone runs rm -r on the directory containing that translator (which could be a world-writable one such as tmp), the rm -r will descend into the directory, and thus remove it with the permissions of the user who ran the rm -- not the one who set up the translator oh i see, when tmp gets cleared by a script run as root, your home is deleted ? right of course, the workaround is trivial: just don't follow translators set up by untrusted users (which is precisely the default policy for FUSE BTW) which is the general policy around memory managers in general it's just nobody cared to implement this change antrik: does rm use O_NOTRANS ? youpi: I'm pretty sure it doesn't so it's still an issue for now yes, it's still an issue. it's just not a really fundamental problem as macrus claimed it to be... [sigh] well, fix rm and then you can say it's not an issue any more does it only concern rm ? youpi: rm is just an example. the problem is much more generic: a malicious translator can do all kinds of harm sure it's just about tools not blindly following things the only simple and effective answer is not to follow translators from untrusted users by default antrik: but then /dev/null can't be non-root depends how "untrusted users" are identified we discussed a more sophisticated solution with cfhammer, that would change the way reauthentication works in lookups, and should prevent these kinds of permission escalation without preventing desirable uses... but it still wouldn't address DOS issues, so it would be only a partial solution youpi: why should it? (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html for the most sophisticated solution) braunr: well, currently the permission system generally trusts root and the own user. implementing something else might be tricky... not sure manuel: yes, that's precisely the discussion I was referring to... thanks for the link :-) antrik: depends what you mean by "follow" what DOS are you thinking of? youpi: a translator can generate endless amounts of "data"; a translator can generate endless recursive directory tress; or it can just never return from RPCs... all things that can do pretty much harm depending on the situation filesystem clients generally trust filesystem operations to be safe -- and that's just not true anymore with filesystems run by untrusted users (be it Hurd translators or FUSE modules) this is a fundamental problem as marcus and neal rightly observed I just don't agree about the seriousness of the consequences I don't think not following untrusted translators really looses us much EDOOMANYNEGATIONS s/D/T again, what do you mean by "following" ? always use O_NOTRANS ? Yes, I think. or never accept a REAUTH ? O_NOTRANS would mean ftpfs running as root, brrr it's not really true that clients always trust filesystem operations the "not returning" case for instance, also appears with nfs mounts no, not always use O_NOTRANS. just be more selective about what translators to follow. specifically, don't follow translators set up by untrusted users. (unless explicitly requested) you can think of it as O_NO_UNTRUSTED_TRANS note that if you run ftpfs under a special user, who is not root but trusted by root, this would still be fine. I hope it shouldn't be too hard to implement that... as for NFS: clients generally do *not* try to catch possible failures. if the NFS server doesn't return, the clients hang forever. but the NFS server is generally trusted, so this is not much of a problem BTW, I guess not accepting reauth from untrusted translators would also fix the privilege escalations (similar to the proposed modified reauth mechanism, only more invasive); but it wouldn't fix the DoS issues antrik: would that also be an issue for a run translator, which runs a command on read? youpi: couldn’t ftpfs have root drop priviledges? like a runas trans essertially su for translators to drop privs ArneBab: hm... if we can make sure that the translator was started as root, and dropped privileges later, I guess that would be fine... not sure how hard that is ArneBab: but I think it would be more elegant to start the translators as trusted non-root users in the first place then i ph.avme to trust them deper hierarchy deeper but essertially the same if then someone mounted his home himself, would I be able to read it? /home/user antrik: if not, that would be really non-nice ArneBab: sorry, but we simply *can't* trust a translator set up by an untrusted user. if he controls it, he can make it behave maliciously we could in theory try to come up with a proxy that catches problematic semantics, and presents a "safe" variant to the actual clients... but that would be not-trivial, and I'm not sure how safe it can be made ArneBab: of course you should always have the option to explicitly say that you want to trust the translator, if you think the user doesn't have malicious intentions :-) (I think nsmux would be a good way to achieve this...) unless it's really really necessary (and i don't see why it would be), no design should force a process to start with privileges and drop them having a set of trusted users (e.g. uid < 100) is a nice solution to the problem imho or part of a group, 100 is a non-hurdish static limit What user is running a passive translator? passive translators are a pain for such things :/ a command line and attach point are not enough to persistently encode the execution context of the tranlator What user is running a passive translator? sorry the one owning the inode if i'm right so actually the orly problem are recursive commands, which also are a problem with plain symlinks? i'm not sure Is thene any havoc a translator can wreak that a symlink can’t? well, as symlinks are translators, if a translator can damage something, a symlink may too but not in Linux? err there are no translator in linux → commands could just treat translators as symlinks jepp, but it has symlinks no, this would defeat the purpose of translators :p and it's just no doable you would have recursion everywhere why? because every file access is sent to a translator hm, yes and we don't want to change commands we want to fix the design → only untrusted trans rather than considering them as symlinks, just consider them as untrusted translators this doesn't change the semantics, only the action of accessing a node or not but as antrik said, this has to be done :) the real problem would simplify to "how do you know if a translator can be trusted", which is a matter of selecting the righ identification strategy one strong strategy would be to have a port right copied to each trusted task i wonder if one of the special ports could be used for that or if we have to add a new one so when I login, I would give port rights to trusted uids? no when a trusted translator starts a passive translator attached on a node owned by root, it would copy its trusted right to the new task much like the device master port is passed to root tasks but i'm not sure this mechanism can be safely used to know if the translator can be trusted the translator would be able to actively call services requiring this capability but i guess client tasks would have to ask for the translator to prove it's trusted which is a problem because the issue is to know if it can be trusted before asking it anything another way is to register trusted tasks in another server, and ask this server if the target translator is trusted i"m pretty sure these strategies already exist in some form on the hurd hm does someone here have an idea why BSD-derived VMs account wiring information at the high level vm_map instead of storing it in lower level vm_page ? braunr: a translator anywhene in the FS can only be there, if the creator had sufficient rights to the node, right? so wouldn’t it suffice to check the access rights? no ismple example: /dev/null is owned by root, but you have read access to it hm that may not answer your question actually what access right would you check ? if someone creates a node with rights 777, do you still want to access it ? no simple enough i hope :) arg… if I can write to it, I can give it a translaton translator but this doesn't tell you it can be trusted well, actually: yes, access, but not recurse the owner sets his own rights, and you can't trust the owner unless it's root, but you don't want all your translators to run as root it can act as its owner? yes well, as i told you, a passive translator is started by its parent translator (the one managing the file systeme node it's attached to) the new translator runs as the user owning the node (if i'm right) …and so on, till noot starts the first root ? root starts /, right? no gnumach starts / ah, right gnumach starts somefs.static which attaches at / and runs with root privileges keep in mind that unix permissions are implemented as capabilities on the hurd → root has it / it’s root the rights you have aren't limited to those permissions jepp and it's not "until" so why should I not access a translator run by someone else? I just don’t want to do any active command (recurse)… hm… can a translator turn a read request into a write? that's the only problem program with my rights wants to read, but the translator makes it write instead? no a translator can do pretty much anything with your request with my rights? no the most obvious example of DoS is simply not answering your process hangs considering some file system accesses, a translator could return inconsistent data so if the translator tries to make me write instead of read, it can do so only when the owner of the translaton can write to the file in question? a well written application shouldn't have too much trouble dealing with it but some aren't that well written this has *nothing* to do with read/write permissions you should read the critique :p [[hurd/critique]] ln -s /home/you /home/me → “why don’t you look into my home?” read it again, that is :) (has been some time since I read it) braunr: you just described the auth mechanism ;-) ArneBab: symlinks can do considerably less than translators; and even these caused a lot of trouble when introduced (and still cause sometimes) we can't make every application aware of translators indeed I believe we can a avoid many problems by presenting various translators as symlinks -- but this is not approriate for all translators it is something the translator itself decides, so it's not helpful to solve security issues at all 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. Likewise, Kees Cook, [fs: symlink restrictions on sticky directories](http://lwn.net/Articles/468215/), 2011-11-18. [2011-12-06 update](http://lwn.net/Articles/470891/). Jake Edge, [Fixing the symlink race problem](http://lwn.net/Articles/472071/), 2011-12-14. # IRC, freenode, #hurd, 2011-08-31 I don't see any problems with following only translators of trusted users where to store the list of trusted users? is there a way to access the underlying node, which for /dev entries belongs to root? youpi: why a list of trusted users? Does it not suffice to require /hurd/trust set by root or ourselves? ArneBab: just because that's what antrik suggests, so I ask him for more details ah, ok youpi: probably make them members of a group 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 ArneBab: we can't set a translator on top of another user's translator in general root could, but that's not very flexible... the group-based solution seems more useful to me antrik: why can’t we? also note that you can't set passive translators on top of other translators ArneBab: because we can only set translators on our own nodes active ones, too? yes antrik: I always thought I could… but did not test it 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 it should be your normal right to change stuff not belonging to you? that's an odd world view :-) subhurds don't really have anything to do with it change it in a way that only I see the changes you need local namespaces to allow making local modifications to global resources it should be one's normal right to change the view one has of it we discussed that once actually I believe... err... private namespaces I mean IRC, freenode, #hurd, 2011-09-10: 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: 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 antrik, but are legacy programs somehow protected? What about executing `find`? Or is GNU's find somehow protected from that? cjuner: I'm talking about a global policy antrik, and who would implement that policy? cjuner: either glibc or the parent translators Continued discussion about [[resource_management_problems/pagers]].