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
<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
Linux kernel, Symlink/Hardlink Attack
Even though not directly comparable, the issues described at Symlink Protection and Hardlink Protection do bear some similarity with the issue we're discussing here.
Likewise, Kees Cook, fs: symlink restrictions on sticky directories, 2011-11-18. 2011-12-06 update. Jake Edge, Fixing the symlink race problem, 2011-12-14.
IRC, freenode, #hurd, 2011-08-31
<antrik> I don't see any problems with following only translators of
trusted users
<youpi> where to store the list of trusted users?
<youpi> is there a way to access the underlying node, which for /dev
entries belongs to root?
<ArneBab> youpi: why a list of trusted users? Does it not suffice to
require /hurd/trust set by root or ourselves?
<youpi> ArneBab: just because that's what antrik suggests, so I ask him for
more details
<ArneBab> ah, ok
<antrik> youpi: probably make them members of a group
<antrik> 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
<antrik> ArneBab: we can't set a translator on top of another user's
translator in general
<antrik> root could, but that's not very flexible...
<antrik> the group-based solution seems more useful to me
<ArneBab> antrik: why can’t we?
<antrik> also note that you can't set passive translators on top of other
translators
<antrik> ArneBab: because we can only set translators on our own nodes
<ArneBab> active ones, too?
<antrik> yes
<ArneBab> antrik: I always thought I could…
<ArneBab> but did not test it
<ArneBab> 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
<antrik> it should be your normal right to change stuff not belonging to
you? that's an odd world view :-)
<antrik> subhurds don't really have anything to do with it
<ArneBab> change it in a way that only I see the changes
<antrik> you need local namespaces to allow making local modifications to
global resources
<youpi> it should be one's normal right to change the view one has of it
<antrik> we discussed that once actually I believe...
<antrik> err... private namespaces I mean
IRC, freenode, #hurd, 2011-09-10:
<cjuner_> 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:
<antrik> 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
<cjuner> antrik, but are legacy programs somehow protected? What about
executing `find`? Or is GNU's find somehow protected from that?
<antrik> cjuner: I'm talking about a global policy
<cjuner> antrik, and who would implement that policy?
<antrik> cjuner: either glibc or the parent translators
Continued discussion about pagers.
IRC, freenode, #hurd, 2013-02-24
<braunr> on a more general topic, i've been thinking about client and
server trust
<braunr> there have been many talkbs about it regarding l4/coyotos/hurdng
<youpi> I generally think the client can trust the server
<braunr> and passing the select timeout to servers corroborates this
<youpi> because it's either root, or it's the same user
<braunr> hum yes, but that's not exactly my question, you'll see
<braunr> there is one feature the hurd has, and i'm not sure we should have
it considering what it requires
<braunr> the feature is that clients can, at any time, "break" from a
server
<youpi> "break" ?
<braunr> the current implementation is to cancel the current RPC after 3
seconds without a reply when the user sends SIGINT
<braunr> the problem is that, moving to a complete migrating thread model
would make that impossible (or very complicated to do right)
<braunr> would it be ok to remove this feature ?
<youpi> well, we need to have SIGINT working, don't we?
<braunr> obviously
<braunr> but that's not what the feature is meant to do
<braunr> it allows clients to recover from a server that misbehaves and
doesn't return
<youpi> then I don't understand in enough details what you mean :)
<braunr> imagine a buggy driver in linux that gets into an uninterruptible
sleep
<braunr> you can't even kill your process
<braunr> that's what the feature is meant to solve
<youpi> that's a quite useful thing
<youpi> e.g. stuck nfs etc., it's useful to be able to recover from that
<braunr> forbidding uninterruptible sleeps would also be a solution, but
then it means relying on servers acting right
<braunr> which is why i mention we usually trust servers
<youpi> well, there is "trust" and "trust" :)
<youpi> i.e. security-wise and robustness-wise
<youpi> I meant clients can usually trust servers security-wise
<braunr> my current idea for x15 is to forbid this kind of breaking, but
also forbid uninterruptible sleeps
<youpi> robustness-wise, I'd say no
<braunr> this way, sending a signal directly reaches the server, which is
trusted to return right away (well, conforming to the handling behaviour)
<braunr> so yes, buggy servers would prevent that, but on the other hand,
stuck nfs wouldn't
<youpi> provided the nfs implementation is not bogus
<braunr> yes
<youpi> I'd tend to agree, but would rather see this discussed on the list
<braunr> yes
<braunr> actually, it wouldn't be that hard to keep the current behaviour,
since i won't implement true migrating threads
<braunr> but it means retaining some issues we have (most importantely,
denial of service)
<braunr> -e
<braunr> what i want to avoid is
http://www.gnu.org/software/hurd/hurd/ng/cancellationforwarding.html
<youpi> for non-trusted servers, we could have a safety wrapper
<youpi> which we trust and does things carefully when talking with the
non-trusted server
<braunr> what would a non trusted server be ?
<youpi> whatever is neither root nor me
<youpi> e.g. nobody-provided /ftp:, or $HOME of another user, etc.
<braunr> i'd argue we don't talk to non trusted servers at all, period
<youpi> users won't like it :)
<braunr> and i'd extend root to a system provided list
<youpi> actually the nobody /ftp: case is important
<braunr> users should be able to create their own list of trusted users
<youpi> it's also the nobody /dev/null case
<youpi> atm it's root
<braunr> yes
<braunr> i see the point
<braunr> i'm just saying the idea of "using non-trusted server" doesn't
make sense
<youpi> actually running /ftp: under nobody is dangerous
<youpi> since if you're running as nobody (because you broke into the
system or whatever), then you can poke with nobody-provided servers
<braunr> yes
<youpi> so we'd rather have really-nobody processes
<braunr> taht's an already existing problem
<youpi> which can't be poked into
<youpi> (and thus can't poke into each other)
<braunr> or a separate user for each
<youpi> that'd be difficult
<braunr> or separate tokens, it's not important
<youpi> for /ftp:/ftp.debian.org used by someone, and /ftp:/ftp.foo.org
used by someone else
<braunr> what i mean is that, by talking to a server, a client implicitely
trusts it
<braunr> youpi: wouldn't that just be the same "ftp" user ?
<youpi> ideally, a carefully-crafted client could avoid having to trust it
<braunr> really ?
<youpi> braunr: that's the problem: then each ftpfs can poke on each other
<braunr> well, each global one
<youpi> there's the daemon-sharing issue too, yes
<braunr> i wasn't thinking about ftpfs, but rather the "system" pfinet for
example
<youpi> like /dev/null is shared
<braunr> when you say root or me, it's "system" or me
<braunr> by default, users trust their system
<braunr> they don't trust other users
<youpi> avoid having to trust it: yes, by using timeouts etc.
<braunr> that's clearly not enough
<youpi> why?
<braunr> shapiro described this in a mail but i can't find it right now
<youpi> I wouldn't like to have to trust ftpfs
<braunr> well time is one thing, data provided for example is another
<braunr> well, you do
<youpi> who knows what bug ftpfs has
<youpi> ideally I would be able not to have to
<youpi> braunr: you can check data
<braunr> i don't think that ideal is possible
<braunr> it you set a ftp translator with a user account, you give it the
password
<youpi> which password?
<braunr> the account password
<youpi> which account?
<braunr> "a user account"
<braunr> i.e. not anonymoius
<youpi> ah
<youpi> well, sure, you have to give that to ftpfs
<youpi> I mean the ftp server might be malicious or whatever
<youpi> and trigger a bug in ftpfs
<braunr> yes
<youpi> so I don't want to have to trust ftpfs
<braunr> what would that mean in practice ?
<youpi> have a trusted translation layer which papers over it, checking
timeouts & data
<braunr> how do you check data ?
<youpi> by knowing the protocol
<braunr> ?
<braunr> can you give a quick example ?
<youpi> well, which data check do you need?
<youpi> (it's you who mentioned data issues :) )
<braunr> i don't know what you mean by that so, choose as you see fit
<braunr> well the password one for example
<braunr> i was merely saying that, buy using an application, be it a
regular one or a translator, you automatically trust it
<youpi> you mean the ftp user password ?
<braunr> it becomes part of your tcb
<youpi> of course you have to provide it to ftpfs
<youpi> that's not a problem
<youpi> yes, but it's not because you connect to an http website that you
trust the webserver on the other end
<youpi> your web browser does checking for you
<braunr> when the protocol allows it
<braunr> (in this case, i'm thinking assymmetrical cryptography)
<youpi> in which case example doesn't it ?
<youpi> it seems we're not talking about the same kind of issue, thus not
understanding each other
<braunr> indeed
<youpi> by "trusting", I don't mean "be sure that it's the right server at
the other end"
<braunr> my point is that not trusting a server is impossible
<youpi> I mean "it behaves correectly"
<braunr> yes
<braunr> it may not behave correctly, and we might not know it
<youpi> as long as it doesn't make the program crash, that's fine
<youpi> that's what I mean
<braunr> that's where the difference is
<youpi> but giving the password is not my concern here
<youpi> and giving the password is a matter of cryptography, etc. yes, but
that's completely not my point
<braunr> i'm concerned about absolute correct behaviour
<braunr> hm
<braunr> no actually i was
<braunr> but not any more, the discussion has shifted back to the timeout
issue
<braunr> ah no, i remember
<braunr> we talked about which servers to trust
<braunr> and how to alter communication accordingly
<braunr> 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
<braunr> the wrapper would help for this specific blocking issue, yes
<youpi> I don't agree on this
<youpi> let me take a way more simple example
<youpi> a server that provides data through io_read
<youpi> I don't want to trust it because it's provided by some joe user
<youpi> but I still want to have a look at the data that it produces
<youpi> I'm fine that the data may be completely non-sense, that's not a
problem
<youpi> what is a problem, however, is if the hexdump program I've run over
it can't be ^C-ed
<braunr> yes, that's the specific issue i mentioned
<youpi> and for that, a mere trusted intermediate could be enough
<braunr> iirc, there is a firmlink-related issue
<youpi> ?
<braunr>
http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html
<youpi> I'm not able to guess what conclusion you are drawing here :)
<braunr> don't talk to untrusted servers
<youpi> or be careful
<youpi> the rm -fr /tmp being aabout being careful actually
<braunr> right
<braunr> i have a very unix-centric view for my system actually
<braunr> i think posix compatibility is very important for me
<braunr> more than it seems to have been in the past when the hurd was
designed
<braunr> to* me
<braunr> so i don't trust tools to be careful
<youpi> that's why a wrapping translator could make it back to posix
compatibility
<braunr> but i see what you mean
<youpi> being careful for the tools
<braunr> hum, a wrapping _translator_ ?
<youpi> yes, similar to remap and fakeroot
remap root translator, fakeroot.
<braunr> ok
<youpi> you'd tell it "for this path, please be careful for my tools"
<braunr> ok so
<braunr> it would basically still end up trusting system or me
<braunr> but you'd add this wrapper to the system
<youpi> "it" ?
<braunr> the situation
<braunr> i don't know :)
<braunr> the implementation, whatever
<youpi> the shell I'm running, you mean
<braunr> and it would be the job of this translator to shield the user
<youpi> yes
<braunr> that's a good idea, yes
<youpi> it could reduce the allowed RPC set to what it knows to check
<braunr> how would the shell use it ?
<braunr> would it "shadow" / ?
<youpi> yes
<braunr> ok