On 2012-03-16, Sebastian Hahn <hahn....@web.de> wrote: > > On Feb 10, 2012, at 12:02 AM, Robert Ransom wrote: >> The sole exception to ‘non-safe cookie authentication must die’ is >> when a controller knows that it is connected to a server process with >> equal or greater access to the same filesystem it has access to. In >> practice, this means ‘only if you're completely sure that Tor is >> running in the same user account as the controller, and you're >> completely sure that you're connected to Tor’, and no controller is >> sure of either of those. > > Why is it so hard to do this?
I am not aware of any sane way for a program to determine which user ID is on the other end of a TCP socket, even over the loopback interface. (Scraping the output of netstat or sockstat or lsof is insane.) > Can't we tell controllers to do a > check of permissions, and only if they can't be sure refuse to use the > requested path by default unless a config whitelist or user prompt > allows it? I think that's a lot easier to implement for controllers, and > I just don't really see the huge threat here. If you have malicious > system-wide software on your host, you lost anyway. * Not every program which can receive connections on the loopback interface should be allowed to read every 32-byte file which I can access. (Such programs might not have access to any part of my filesystem.) * If Tor were intended to have read access to every file in my user account, the Debian package would configure it to keep running as root (even after startup). * If an attacker compromises the Tor process after it has dropped privileges, Tor can fool a controller into opening the wrong file by dropping a symlink in the whitelisted location for the system-wide cookie file. There is no good way to avoid following a symlink when opening a file. (O_NOFOLLOW isn't a good way -- it still follows parent-directory symlinks, it may not be available on all OSes, and it is not likely to be available in all programming languages.) fstat (to check ownership and permissions after opening a cookie file) is difficult enough to use that someone will not use it, even if their controller can correctly guess what ownership and permissions the cookie file should have. * A user who configures a controller to connect to a remote Tor instance's control port knows that he/she/it is allowing attackers on the LAN to control the Tor instance. He/she/it is unlikely to know that attackers on the LAN can also read 32-byte files from his/her/its client system's disk. * I will have very sensitive 32-byte files in my Unixoid VFS tree Real Soon Now. Perhaps other people will, too. * A subtle complex flaky kludge which most controller implementors will not realize is necessary is not a valid substitute for a simple new cookie-based authentication protocol that avoids filesystem permission-check hacks entirely. Robert Ransom _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
