From 12c341b917921eb631026ec44a284c4d884e5de6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 6 Mar 2013 21:52:20 +0100 Subject: IRC. --- .../translators_set_up_by_untrusted_users.mdwn | 229 ++++++++++++++++++++- 1 file changed, 228 insertions(+), 1 deletion(-) (limited to 'open_issues/translators_set_up_by_untrusted_users.mdwn') diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn index 1dac130c..521331e9 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 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013 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 @@ -350,3 +350,230 @@ IRC, freenode, #hurd, 2011-09-14: 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 + 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 -- cgit v1.2.3