[[!meta copyright="Copyright © 2011, 2013, 2014 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]]. # IRC, freenode, #hurd, 2013-02-24 on a more general topic, i've been thinking about client and server trust there have been many talkbs about it regarding l4/coyotos/hurdng I generally think the client can trust the server and passing the select timeout to servers corroborates this because it's either root, or it's the same user hum yes, but that's not exactly my question, you'll see there is one feature the hurd has, and i'm not sure we should have it considering what it requires the feature is that clients can, at any time, "break" from a server "break" ? the current implementation is to cancel the current RPC after 3 seconds without a reply when the user sends SIGINT the problem is that, moving to a complete migrating thread model would make that impossible (or very complicated to do right) [[mach_migrating_threads]]. would it be ok to remove this feature ? well, we need to have SIGINT working, don't we? obviously but that's not what the feature is meant to do it allows clients to recover from a server that misbehaves and doesn't return then I don't understand in enough details what you mean :) imagine a buggy driver in linux that gets into an uninterruptible sleep you can't even kill your process that's what the feature is meant to solve that's a quite useful thing e.g. stuck nfs etc., it's useful to be able to recover from that forbidding uninterruptible sleeps would also be a solution, but then it means relying on servers acting right which is why i mention we usually trust servers well, there is "trust" and "trust" :) i.e. security-wise and robustness-wise I meant clients can usually trust servers security-wise my current idea for x15 is to forbid this kind of breaking, but also forbid uninterruptible sleeps robustness-wise, I'd say no this way, sending a signal directly reaches the server, which is trusted to return right away (well, conforming to the handling behaviour) so yes, buggy servers would prevent that, but on the other hand, stuck nfs wouldn't provided the nfs implementation is not bogus yes I'd tend to agree, but would rather see this discussed on the list yes actually, it wouldn't be that hard to keep the current behaviour, since i won't implement true migrating threads but it means retaining some issues we have (most importantely, denial of service) -e what i want to avoid is http://www.gnu.org/software/hurd/hurd/ng/cancellationforwarding.html for non-trusted servers, we could have a safety wrapper which we trust and does things carefully when talking with the non-trusted server what would a non trusted server be ? whatever is neither root nor me e.g. nobody-provided /ftp:, or $HOME of another user, etc. i'd argue we don't talk to non trusted servers at all, period users won't like it :) and i'd extend root to a system provided list actually the nobody /ftp: case is important users should be able to create their own list of trusted users it's also the nobody /dev/null case atm it's root yes i see the point i'm just saying the idea of "using non-trusted server" doesn't make sense actually running /ftp: under nobody is dangerous since if you're running as nobody (because you broke into the system or whatever), then you can poke with nobody-provided servers yes so we'd rather have really-nobody processes taht's an already existing problem which can't be poked into (and thus can't poke into each other) or a separate user for each that'd be difficult or separate tokens, it's not important for /ftp:/ftp.debian.org used by someone, and /ftp:/ftp.foo.org used by someone else what i mean is that, by talking to a server, a client implicitely trusts it youpi: wouldn't that just be the same "ftp" user ? ideally, a carefully-crafted client could avoid having to trust it really ? braunr: that's the problem: then each ftpfs can poke on each other well, each global one there's the daemon-sharing issue too, yes i wasn't thinking about ftpfs, but rather the "system" pfinet for example like /dev/null is shared when you say root or me, it's "system" or me by default, users trust their system they don't trust other users avoid having to trust it: yes, by using timeouts etc. that's clearly not enough why? shapiro described this in a mail but i can't find it right now I wouldn't like to have to trust ftpfs well time is one thing, data provided for example is another well, you do who knows what bug ftpfs has ideally I would be able not to have to braunr: you can check data i don't think that ideal is possible it you set a ftp translator with a user account, you give it the password which password? the account password which account? "a user account" i.e. not anonymoius ah well, sure, you have to give that to ftpfs I mean the ftp server might be malicious or whatever and trigger a bug in ftpfs yes so I don't want to have to trust ftpfs what would that mean in practice ? have a trusted translation layer which papers over it, checking timeouts & data how do you check data ? by knowing the protocol ? can you give a quick example ? well, which data check do you need? (it's you who mentioned data issues :) ) i don't know what you mean by that so, choose as you see fit well the password one for example i was merely saying that, buy using an application, be it a regular one or a translator, you automatically trust it you mean the ftp user password ? it becomes part of your tcb of course you have to provide it to ftpfs that's not a problem yes, but it's not because you connect to an http website that you trust the webserver on the other end your web browser does checking for you when the protocol allows it (in this case, i'm thinking assymmetrical cryptography) in which case example doesn't it ? it seems we're not talking about the same kind of issue, thus not understanding each other indeed by "trusting", I don't mean "be sure that it's the right server at the other end" my point is that not trusting a server is impossible I mean "it behaves correectly" yes it may not behave correctly, and we might not know it as long as it doesn't make the program crash, that's fine that's what I mean that's where the difference is but giving the password is not my concern here and giving the password is a matter of cryptography, etc. yes, but that's completely not my point i'm concerned about absolute correct behaviour hm no actually i was but not any more, the discussion has shifted back to the timeout issue ah no, i remember we talked about which servers to trust and how to alter communication accordingly and my point was that altering communication shouldn't be done, we either trust the server, and talk to it, or we don't, and we stay away the wrapper would help for this specific blocking issue, yes I don't agree on this let me take a way more simple example a server that provides data through io_read I don't want to trust it because it's provided by some joe user but I still want to have a look at the data that it produces I'm fine that the data may be completely non-sense, that's not a problem what is a problem, however, is if the hexdump program I've run over it can't be ^C-ed yes, that's the specific issue i mentioned and for that, a mere trusted intermediate could be enough iirc, there is a firmlink-related issue ? http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html I'm not able to guess what conclusion you are drawing here :) don't talk to untrusted servers or be careful the rm -fr /tmp being aabout being careful actually right i have a very unix-centric view for my system actually i think posix compatibility is very important for me more than it seems to have been in the past when the hurd was designed to* me so i don't trust tools to be careful that's why a wrapping translator could make it back to posix compatibility but i see what you mean being careful for the tools hum, a wrapping _translator_ ? yes, similar to remap and fakeroot [[virtualization/remap_root_translator]], [[virtualization/fakeroot]]. ok you'd tell it "for this path, please be careful for my tools" ok so it would basically still end up trusting system or me but you'd add this wrapper to the system "it" ? the situation i don't know :) the implementation, whatever the shell I'm running, you mean and it would be the job of this translator to shield the user yes that's a good idea, yes it could reduce the allowed RPC set to what it knows to check how would the shell use it ? would it "shadow" / ? yes ok