diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/systemd.mdwn | 68 | ||||
| -rw-r--r-- | open_issues/translators_set_up_by_untrusted_users.mdwn | 274 |
2 files changed, 341 insertions, 1 deletions
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 + + <pinotree> 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... + <pochu> yeah, I've read the thread + <pochu> it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + <pochu> we'll see + <pinotree> you can always help me with kde on hurd, would be nice ;) + <pochu> hehe + <pinotree> 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 + <pochu> yeah... it doesn't come from all the community though + <pochu> I'm sure some people have always thought that way + <tschwinge> Or we could get systemd going? :-) + <pochu> good luck with that :p + <guillem> tschwinge: haha!? :) + <tschwinge> That bad? + <guillem> tschwinge: if you mean by that forking indefinitely then maybe + <guillem> tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + <guillem> or even older Linux versions! + <guillem> to the point of rejecting patches, because they "clutter" the + source code... + <tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-) + <guillem> tschwinge: then you'll be always playing catch up + <guillem> 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 + <tschwinge> Yeah. I'm half-serious, half-joking. + <tschwinge> I haven't looked at the systemd code at all. + <guillem> + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + <guillem> some are just glibc extensions though + <guillem> and some are IMO optional and should be conditionalized, but... + <guillem> 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 :) + <guillem> as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + <guillem> 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 :) + <guillem> 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 + <pochu> 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 + :) + <tschwinge> We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/> + <guillem> 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 + <guillem> witness HAL, ConsoleKit, etc etc + <guillem> (anyway enough ranting I guess :) + <tschwinge> Yeah, it's true, though. + <pochu> 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 + + <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK + it doesn't actually apply to firmlinks ;-) + <antrik> 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 + <braunr> but this doesn't supersede the file system permissions, does it ? + <antrik> 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 + <braunr> oh i see, when tmp gets cleared by a script run as root, your home + is deleted ? + <antrik> right + <antrik> of course, the workaround is trivial: just don't follow + translators set up by untrusted users + <antrik> (which is precisely the default policy for FUSE BTW) + <braunr> which is the general policy around memory managers in general + <antrik> it's just nobody cared to implement this change + <youpi> antrik: does rm use O_NOTRANS ? + <antrik> youpi: I'm pretty sure it doesn't + <youpi> so it's still an issue for now + <antrik> yes, it's still an issue. it's just not a really fundamental + problem as macrus claimed it to be... [sigh] + <youpi> well, fix rm and then you can say it's not an issue any more + <braunr> does it only concern rm ? + <antrik> youpi: rm is just an example. the problem is much more generic: a + malicious translator can do all kinds of harm + <youpi> sure + <youpi> it's just about tools not blindly following things + <antrik> the only simple and effective answer is not to follow translators + from untrusted users by default + <youpi> antrik: but then /dev/null can't be non-root + <braunr> depends how "untrusted users" are identified + <antrik> 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 + <antrik> youpi: why should it? + <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html + for the most sophisticated solution) + <antrik> braunr: well, currently the permission system generally trusts + root and the own user. implementing something else might be tricky... not + sure + <antrik> manuel: yes, that's precisely the discussion I was referring + to... thanks for the link :-) + <youpi> antrik: depends what you mean by "follow" + <youpi> what DOS are you thinking of? + <antrik> 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 + <antrik> filesystem clients generally trust filesystem operations to be + safe -- and that's just not true anymore with filesystems run by + untrusted users + <antrik> (be it Hurd translators or FUSE modules) + <antrik> this is a fundamental problem as marcus and neal rightly observed + <antrik> I just don't agree about the seriousness of the consequences + <antrik> I don't think not following untrusted translators really looses us + much + <youpi> EDOOMANYNEGATIONS + <youpi> s/D/T + <youpi> again, what do you mean by "following" ? + <youpi> always use O_NOTRANS ? + <tschwinge> Yes, I think. + <youpi> or never accept a REAUTH ? + <youpi> O_NOTRANS would mean ftpfs running as root, brrr + <youpi> it's not really true that clients always trust filesystem + operations + <youpi> the "not returning" case for instance, also appears with nfs mounts + <antrik> 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) + <antrik> you can think of it as O_NO_UNTRUSTED_TRANS + <antrik> 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... + <antrik> 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 + <antrik> 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 + <ArneBab> antrik: would that also be an issue for a run translator, which + runs a command on read? + <ArneBab> youpi: couldn’t ftpfs have root drop priviledges? + <ArneBab> like a runas trans + <ArneBab> essertially su for translators to drop privs + <antrik> 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 + <antrik> ArneBab: but I think it would be more elegant to start the + translators as trusted non-root users in the first place + <ArneBab> then i ph.avme to trust them + <ArneBab> deper hierarchy + <ArneBab> deeper + <ArneBab> but essertially the same + <ArneBab> if then someone mounted his home himself, would I be able to read + it? + <ArneBab> /home/user + <ArneBab> antrik: if not, that would be really non-nice + <antrik> 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 + <antrik> 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 + <antrik> 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 :-) + <antrik> (I think nsmux would be a good way to achieve this...) + <braunr> 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 + <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution + to the problem imho + <braunr> or part of a group, 100 is a non-hurdish static limit + <ArneBab> What user is running a passive translator? + <braunr> passive translators are a pain for such things :/ + <braunr> a command line and attach point are not enough to persistently + encode the execution context of the tranlator + <ArneBab> What user is running a passive translator? + <ArneBab> sorry + <braunr> the one owning the inode if i'm right + <ArneBab> so actually the orly problem are recursive commands, which also + are a problem with plain symlinks? + <braunr> i'm not sure + <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t? + <braunr> well, as symlinks are translators, if a translator can damage + something, a symlink may too + <ArneBab> but not in Linux? + <braunr> err + <braunr> there are no translator in linux + <ArneBab> → commands could just treat translators as symlinks + <ArneBab> jepp, but it has symlinks + <braunr> no, this would defeat the purpose of translators :p + <braunr> and it's just no doable + <braunr> you would have recursion everywhere + <ArneBab> why? + <braunr> because every file access is sent to a translator + <ArneBab> hm, yes + <braunr> and we don't want to change commands + <braunr> we want to fix the design + <ArneBab> → only untrusted trans + <braunr> rather than considering them as symlinks, just consider them as + untrusted translators + <braunr> this doesn't change the semantics, only the action of accessing a + node or not + <braunr> but as antrik said, this has to be done :) + <braunr> 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 + <braunr> one strong strategy would be to have a port right copied to each + trusted task + <braunr> i wonder if one of the special ports could be used for that + <braunr> or if we have to add a new one + <ArneBab> so when I login, I would give port rights to trusted uids? + <braunr> no + <braunr> 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 + <braunr> much like the device master port is passed to root tasks + <braunr> but i'm not sure this mechanism can be safely used to know if the + translator can be trusted + <braunr> the translator would be able to actively call services requiring + this capability + <braunr> but i guess client tasks would have to ask for the translator to + prove it's trusted + <braunr> which is a problem because the issue is to know if it can be + trusted before asking it anything + <braunr> another way is to register trusted tasks in another server, and + ask this server if the target translator is trusted + <braunr> i"m pretty sure these strategies already exist in some form on the + hurd + <ArneBab> hm + <braunr> 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 ? + <ArneBab> braunr: a translator anywhene in the FS can only be there, if the + creator had sufficient rights to the node, right? + <ArneBab> so wouldn’t it suffice to check the access rights? + <braunr> no + <braunr> ismple example: /dev/null is owned by root, but you have read + access to it + <braunr> hm that may not answer your question actually + <braunr> what access right would you check ? + <braunr> if someone creates a node with rights 777, do you still want to + access it ? + <ArneBab> no + <braunr> simple enough i hope :) + <ArneBab> arg… + <ArneBab> if I can write to it, I can give it a translaton + <ArneBab> translator + <braunr> but this doesn't tell you it can be trusted + <ArneBab> well, actually: yes, access, but not recurse + <braunr> the owner sets his own rights, and you can't trust the owner + <braunr> unless it's root, but you don't want all your translators to run + as root + <ArneBab> it can act as its owner? + <ArneBab> yes + <braunr> 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) + <braunr> the new translator runs as the user owning the node + <braunr> (if i'm right) + <ArneBab> …and so on, till noot starts the first + <ArneBab> root + <braunr> ? + <ArneBab> root starts /, right? + <braunr> no + <braunr> gnumach starts / + <ArneBab> ah, right + <braunr> gnumach starts somefs.static + <braunr> which attaches at / + <braunr> and runs with root privileges + <braunr> keep in mind that unix permissions are implemented as capabilities + on the hurd + <ArneBab> → root has it / it’s root + <braunr> the rights you have aren't limited to those permissions + <ArneBab> jepp + <braunr> and it's not "until" + <ArneBab> 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? + <braunr> that's the only problem + <ArneBab> program with my rights wants to read, but the translator makes it + write instead? + <braunr> no + <braunr> a translator can do pretty much anything with your request + <ArneBab> with my rights? + <braunr> no + <braunr> the most obvious example of DoS is simply not answering + <braunr> your process hangs + <braunr> considering some file system accesses, a translator could return + inconsistent data + <ArneBab> 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? + <braunr> a well written application shouldn't have too much trouble dealing + with it but some aren't that well written + <braunr> this has *nothing* to do with read/write permissions + <braunr> you should read the critique :p + +[[hurd/critique]] + + <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?” + <ArneBab> read it again, that is :) + <ArneBab> (has been some time since I read it) + <antrik> braunr: you just described the auth mechanism ;-) + <antrik> ArneBab: symlinks can do considerably less than translators; and + even these caused a lot of trouble when introduced (and still cause + sometimes) + <antrik> we can't make every application aware of translators + <antrik> indeed I believe we can a avoid many problems by presenting + various translators as symlinks -- but this is not approriate for all + translators + <antrik> it is something the translator itself decides, so it's not helpful + to solve security issues at all + <antrik> and as braunr already pointed out, this wouldn't help with DoS + problems |