Re: [PATCH 0/7] KDB: Kiosk (reduced capabilities) mode

[Anton Vorontsov]

On Fri, Jul 27, 2012 at 12:30:49PM -0700, Colin Cross wrote:
> > The are two use-cases for the mode, one is evil, but another is quite
> > legitimate.
> >
> > The evil use case is used by some (ahem) phone manufaturers that want
> > to have a debuging facilities on a production device, but still don't
> > want you to use the debugger to gain root access. I don't like locked
> > phones, and I would not touch this/get my hands dirty by implementing
> > the feature just for this evil (IMHO) use case.
> 
> The point of the reduced feature set in FIQ debugger is not to prevent
> you from accessing your own phone, it designed to prevent others from
> trivially rooting your phone and reading your data.  Both locked and
> unlocked phones run FIQ debugger.  Would you carry a phone with
> personal data on it and KGDB enabled on the serial console?

Short answer: yes, I would carry such a phone. :-)

Long answer:

If someone was so interested in cracking the phone/data and so
ended up with attaching serial console and attempted to use debugger 
techniques to gain access to my data, then thief's next step would be
soldering a few wires to JTAG spots, and it will be all done in
minutes. Knowledge-wise, using JTAG is even more trivial than using the
debugger techniques to get to my data, you just need some HW skills.

Of course, this is unless you also have the JTAG somehow vendor-locked,
but then, personally, I consider it as an utter evil. For a person who
really interested in my data, attaching to a flash directly is also not
a problem (the imaginary thief already soldered JTAG and if it didn't
work, soldering a few more wires is not a big deal).

Maybe I'm paranoid here, but for me it is hard to believe that the
reduced set was not considered as a "feature" to make life more
difficult for normal users wanting their device rooted. According to
copyright dates, the FIQ debugger started very early, in 2008, when
most Android phone vendors were very unfriendly to hackers.

Btw, why do the lovely vendors allow me to use an external SD card on
the phone? My data is not protected, but the vendors suddenly no longer
care. So what changed between my data on the external SD card and in the
phone itself? Nothing. Vendors care about the root access itself, not my
data.

Really, I tend to care more about my naked pictures^W^W^W NDA documents
I should not have taken out of the office^W^W^W^W^W loads of private data
on the SD card, and less about my email password stored in phone's
memory. That's because if SD card is stolen/lost, everyone can read it,
any time. And if password is stolen, I have some time to change it.

All I see is a very artful way to sell shackles to naive people, and
this is exactly what phone vendors do by locking their devices. If I
want my data protected, I use encryption with *my* keys, I don't want
to be "protected" by the ways described above.

And the KDB lock doesn't help in a way that thieves no longer need to
disassemble the phone to erase all the data and resell the phone (if
serial port is available outside). A guy who bought the stolen phone
on eBay will never know that the phone was disassembled: only a
professional can tell whether warranty seals are original. The thief
would probably not even bother with restoring the seals, he can always
say that the phone needed a screen replacement. (Now someone might be
wondering why do I know so much about phones' black market... :-)

Still, I'm not saying that the feature is not useful at all, it is
useful. But to me, it is much more useful for public PCs/ATMs, when
a few keystrokes on a panicked ATM can open ATM's money depository.
Or just administrator don't like when wise kids get root (yup) on
classroom's PCs.

But if you say that it wasn't the case, and no one thought about the
reducing the debugger in the "evil" way, so be it, I trust you. But I
still don't trust the phone vendors. They showed their bad attitude
in many ways towards hackers, so I think we both have quite legitimate
reasons to be a little bit paranoid. :-)

> An alternate option would be to allow userspace to write a password
> hash to a sysfs file, and require the password to be entered over the
> serial console to unlock KGDB or enable unsafe KGDB commands.

Yup, that's a very nice idea. This can be implemented by introducing
"unlock" KDB command. Although, that also requires tight integration
w/ user-space, i.e. on boot userland would need to supply hashing
method, salt and root's password hash. The same has to be done on every
password change. It is surely doable, but not sure if it is worth the
efforts. Maybe, some day.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmailru@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/