ubuntu-phone team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

Hello Oliver,

I installed your proposed adbd now, and now adbd shell is a phablet
shell (user, not root) after setting a pin code. There still needs to
be a testing mode for that, as during tests the only thing after
flashing that we have is adb. Also, one now can't launch programs
while the screen lock is on, so all tests fail until the pin is
entered manually.

Oliver Grawert [2014-08-18 11:05 +0200]:
> > However, non-root adb will break some other things in there: It writes
> > into /cache/recovery/ubuntu_command for factory reset, and saves and
> this is fixed already by having the dir owned by the right group and the
> phablet user being in it, you should already be able to put files in
> there as phablet user.

No, I'm not:

$ touch /cache/recovery/foo
touch: cannot touch ‘/cache/recovery/foo’: Permission denied

drwxr-xr-x 2 root root 4096 Aug 19 05:10 /cache/recovery/


> > restores /etc/NetworkManager/system-connections/ before/after factory
> > reset.
> if it actually uses the files this needs to be fixed in factory reset
> code ... 
> phablet-network will use nmcli in the future landings for this are
> pending

I doubt that nmcli can read the existing passwords for wifi
connections?

> >   Running these through adb (or ssh, which is less desirable)
> > would need sudo. I suppose there is no SetPropery call (as an user) to
> > enable sudo, as that would make the whole lockdown pointless.
> this wont make the lockdown pointless as you still need to explicitly
> enable password protection to switch it on ...

Ah, ok. That'll make automatic testing even harder, though :/

> there will be some debus properties i'm currently working on that will
> allow a set of hardcoded commands via sudoers.d snippets ...
> (alternatively we would have to echo the password into scripts and store
> it as clear text on the PC ... i find that less desirable)

For testing we'll use either no password or "phablet" or anything
well-known, so not a problem there ;-)

> > Also, will "adb reboot recovery" still work as non-root?
> > 
> yes, the privilege dropping only happens for adb shell ... the rest of
> adb features still works as known 

Confirmed, that works. But that will again allow you to circumvent the
PIN protection, as you don't need to enter the PIN to run that? I. e.
boot to recovery, flash a new system (or use adb from there as root),
and you are again in the system.

> > I suppose for both things we need a way to enable sudo when flashing
> > the device. Will/does ubuntu-device-flash --developer-mode do that? I.
> > e. we'll set up our test devices with that once, and from then on adb
> > will stay root even after factory reset?
> > 
> we have sudo ... but it is very ugly to use programmatically if you have
> send a password (adbd's tty handling essentially doesnt exist and we
> cant hack it up easily without breaking other core behavior):
> 
> mypassword=1234
> adb shell "echo $mypassword| sudo -S /usr/bin/foople"

Nah, that can be done. Create a little shell script /tmp/pwd with
"echo s3kr1t", and run "SSH_ASKPASS=/tmp/pwd sudo -A foople".

> for all the bits that are used by phablet-tools the necessary dbus
> backends are planned already ... if you do not use phablet-tools in your
> scripts or test tools, please let me know what other dbus properties you
> need ... 

autopkgtest's adb setup script does use phablet-config to disable the
wizard, edges into, and dbus-probe. But there's no phablet-tools
command for resetting to factory status and saving/restoring wifi
connections before/after that, so the script has to do that by itself.
But supposedly phablet-tools would have just as much difficulty with
the above operations as autopkgtest.

In essence, what we need for testing:

 - Flash a device with latest image, with a magic option (or
   post-flashing config) to enable ADB
 - Enable sshd
 - For some tests we might need root access, so for those we need to
   ename that through sudo

It seems phablet-config also fails to enable the dbus-probe (that also
needs root presumably).

and all that without manual interaction or someone having to touch
things or enter PINs.

So in summary, at the moment there is no way to run tests on a touch
phone with that adbd :/

Another question: If your goal is to lock down the device, why do we
start adb by default? It would make much more sense to only enable
that on demand -- when you use your phone, all you (should) need is
MTP, an always running adbd allows you to circumvent the PIN
restriction and access all your data anyway. It's thus still a
security hole.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Attachment: signature.asc
Description: Digital signature