Hi,
Alan wrote (09 Nov 2013 13:14:56 GMT) :
> On Fri, 08 Nov 2013 23:58:18 +0100 intrigeri <intrigeri@???> wrote:
>> I'd like to see someone take 5 minutes to think through the actual
>> disadvantages of a (admitedly ugly) `sleep 5' (or even `sleep 60', to
>> accommodate slower nested virtualization as used in the test suite).
>>
> I fail to see how we would be sure that we sleep long enough. So
> perhaps we could find a fix with sleep that works for all the tests we
> do, but unless we actually wait for the client to connect to X, we
> can't be sure that an hardware that is slow enough to break this won't
> show up.
Again, in theory you're perfectly correct, but in practice we don't
care to be "sure" (in the theoretical meaning you are using this word
here).
Time for a reality check, please. As you know, booting Tails in nested
virtualization within the test suite takes around 10 minutes on some
relatively modern laptop. Let's assume that, in this setting, Vidalia
takes one minute or two between the time it's started and the time it
connects to X. I don't believe Tails will be anything close to usable
on slower hardware than that, and I don't think we can realistically
care about it. So, IMHO a sleep value that's good enough for nested
virtualization is good enough in practice.
Oh $DEITY, my next paragraph in my last email was already about
correctness vs. good enough. I'm repeating myself.
> I was thinking about a patch to x11-utils to add the PID to
> xlsclients output (which would be quite easy), but thought it was a bit
> to much time investement to perhaps have the option in jessie...
Absolutely. Don't hesitate volunteering for the next quarterly tickets
gardening, I'm sure it will help putting this minor issue in
perspective :p
>> So, I guess my real question is: why would an attacker, who supposedly
>> is able to take advantage of the window offered by `sleep 5' (or even
>> `sleep 60'), *not* be able to take advantage of the time between the
>> time door is open and the time it is closed?
>>
> I would say: the shorter the time is, the shorter an attacker would be
> able to use the X authentication.
It's unclear to me if you're affirming this as something you know for
a fact, or if you're roughly guessing.
My guess would be "the shorter an attacker has to set up whatever
process is needed to be able to control X later", but who cares about
my guesses, I'm clueless on this topic :)
> But as I understand things, an
> attacker that would be able to take control of the Vidalia process would
> be authenticated to X anyway,
I'm a newbie in this area, but my first guess is that there may be
a serious difference, in practice, between "being allowed to control
X with arbitrary assembly code running in an existing, authenticated
X client process" and "being able to run arbitrary new X clients".
But maybe not — I've no idea if X authentication is inherited by
child processes.
Anyway, my feeling is that we're fiddling with stuff we aren't very
good at here, and I personally won't put more energy into it until I'm
explained why there is a practical problem that need to be solved
(e.g. an attack that answers the question I asked above).
If anyone thinks it's worth thinking this in more details, IMHO they'd
better take it to someone skilled enough in this area.
> and I don't see why an attacker would
> execute code as the vidalia user if she didn't took control of the
> vidalia process. Am I wrong?
I understand this part the same.
> If I'm right, we don't care that much about closing X auth before
> vidalia exits, right?
Agreed.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
