From e579e2aa506a773d553c5d20b4a7ffa28b0dd4b3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 18 Jul 2011 09:10:29 +0200 Subject: IRC. --- faq/how_many_developers/discussion.mdwn | 43 +++- hurd/translator.mdwn | 3 + open_issues/systemd.mdwn | 68 ++++- .../translators_set_up_by_untrusted_users.mdwn | 274 +++++++++++++++++++++ 4 files changed, 386 insertions(+), 2 deletions(-) create mode 100644 open_issues/translators_set_up_by_untrusted_users.mdwn diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn index 9fc44f25..6ca47c9a 100644 --- a/faq/how_many_developers/discussion.mdwn +++ b/faq/how_many_developers/discussion.mdwn @@ -8,7 +8,48 @@ 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]]."]]"""]] -IRC, freenode, #hurd, 2011-07-09 +# IRC, freenode, #hurd, 2011-05-22 + + Since apparently Hurd's aim is a very stable and transparent + system ...why aren't there any companies backing it up? + silver_hook: it's not in a state yet where it would be + commercially interesting + silver_hook: and after some epic failures in the 90s, few + companies dare to invest in microkernel development... + Isn't MacOS X running on top of Mach? + yes, but it's not a true microkernel system + for one, it's single-server, which is boring + also it uses co-location, i.e. runs all the system code in the + kernel address space -- they are separated only formally + even NT is more of a microkernel system I think + Oh, OK, I'm not that knowledgeable about kernels to know + that. + well, now you know :-) + Yup, thanks :) + most people don't know this, so don't worry + I was just wondering that it might be potentially an ideal + server system, right? + well, *potentially* it might be an ideal general-purpose system, + which includes server use... though personally I think the advantages of + the architecture are more visible in desktop use, as servers tend to be + rather streamlined, with little need for individualisation :-) + however, it still remains to be proven that true (multi-server) + microkernel operating systems actually work for general-purpose + applications... + antrik: I mean regarding hosting or virtual servers. + so far, they are only successful in the much simpler embedded + space + well, yes, the Hurd architecture in theory allows very much + flexibility regarding virtual environments... I once blogged about + that. not sure whether server applications really require that + flexibility though. I think most people are pretty happy with the various + virtualisation/container solutions available in Linux. again, the + flexibility is more relevant in the desktop space IMHO + dosn't mean it wouldn't be useful for servers too... just not as + much of a selling point I fear :-) + + +# IRC, freenode, #hurd, 2011-07-09 gnu_srs1: regarding your question why people aren't interested in workin on Hurd: Eric Raymond explains it pretty well in his famous diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index aa8b966a..33da7afd 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -72,6 +72,9 @@ available. Read about translator [[short-circuiting]]. +The [[concept|concepts]] of translators creates its own problems, too: +[[open_issues/translators_set_up_by_untrusted_users]]. + # Existing Translators diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn index bf8ae70a..12a2699f 100644 --- a/open_issues/systemd.mdwn +++ b/open_issues/systemd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -24,3 +24,69 @@ Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* Daniel Gollub, Stefan Seyfried, 2010-10-14. Likely there's also some other porting needed. + + +# IRC, OFTC, #debian-hurd, 2011-05-19 + + pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + yeah, I've read the thread + it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + we'll see + you can always help me with kde on hurd, would be nice ;) + hehe + pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + yeah... it doesn't come from all the community though + I'm sure some people have always thought that way + Or we could get systemd going? :-) + good luck with that :p + tschwinge: haha!? :) + That bad? + tschwinge: if you mean by that forking indefinitely then maybe + tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + or even older Linux versions! + to the point of rejecting patches, because they "clutter" the + source code... + Well, then let's ``just'' implement the Linux interfaces. :-) + tschwinge: then you'll be always playing catch up + tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + Yeah. I'm half-serious, half-joking. + I haven't looked at the systemd code at all. + + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + some are just glibc extensions though + and some are IMO optional and should be conditionalized, but... + pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. + the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + witness HAL, ConsoleKit, etc etc + (anyway enough ranting I guess :) + Yeah, it's true, though. + agreed diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn new file mode 100644 index 00000000..edc92796 --- /dev/null +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -0,0 +1,274 @@ +[[!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 -- cgit v1.2.3