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)
signature.asc
Description: Digital signature
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp