Hi,

I'm in the process of setting up a Google Nexus 5 with ubports for somebody else. And I keep wondering, what are the security implications of running ubports on a device with unlocked boot-loader?

In case the phone is lost or stolen, will any new "owner" of the device be able to access the WiFi passwords, IMAP passwords and all data, photos etc. stored on the phone by just connecting USB cable and running adb/fastboot to dump the flash?

Are passwords stored on the device encrypted with the unlock passcode?

What precautions can/should be done to secure the data on a phone running ubports?

Thanks for any insights,
cheers,

Dave

Hi,

I sort of start feeling old, trying to participate in UBports: An open source project without a mailing list and without IRC channel does not really integrate with the modes of communication I'm used to use.

Just tried to make a telegram account (via web.telegram.org), however it needs a phone number, and (one of my) "landline" SIP-based phone numbers is not accepted ("incorrect phone number"). I'm not really willing to give my cell phone number to an untrusted 3rd party to participate in an open-source project. I mean, if I were, then I probably would just be using Google Android and not bothering with UBports, would I ?

So I guess I'll have to stay at the outside for now.

cheers,

Dave

Just to document some findings, in case somebody is looking for the same answer: This is how I am using and "integrating" normal Ubuntu and other 3rd-party applications into the launcher:

Creating a libertine image, as documented here.
Example:

libertine-container-manager create -i legacy -n "Legacy"
libertine-container-manager install-package -i legacy -p gnome-terminal
libertine-container-manager install-package -i legacy -p openjdk-8-jre

Now from the OpenStore install package "Desktop Apps". Enable the "Desktop Apps" scope in the launcher. Now swiping left on the Launcher should bring up the "Desktop Apps" scope. After running the commands above it lists just two items: "OpenJDK Java 8 Policy Tool" and "Terminal" . To add other custom launchers (for example to launch some manually installed Java GUI application), you can add more items to the Desktop Apps by creating files inside the libertine container at /usr/share/applications/*.desktop.

Example:

libertine-container-manager install-package -i legacy -p joe
libertine-container-manager install-package -i legacy -p vim
libertine-launch -i legacy  /bin/bash
cp /usr/share/applictions/terminal.desktop /usr/share/applictions/myapp.desktop
joe /usr/share/applications/myapp.desktop

For example to launch a java application installed in /home/phablet/.local/share/libertine-container/user-data/legacy/myapp.jar , edit myapp.desktop and change the line

Exec=/usr/bin/java -jar /home/phablet/myapp.jar

(Note how the container's directory /home/phablet corresponds to the absolute path /home/phablet/.local/share/libertine-container/user-data/legacy/myapp.jar when accessed outside the container)

Dave

Hi,

just to give some more data point: ordered a BQ M10 FHD Ubuntu Edition tablet, arrived yesterday. Installed ubports-installer on a Ubuntu 17.10 linux PC. Tablet initially not detected by the installer, but after setting developer mode, some reboots, trying a different USB port, and manually running "adb" to list connected devices, it "suddenly" started working (hat no prior experience with adb, never used it before).

After detection, installation just completed flawlessly (I configured it to wipe the tablet during installation).

So for now very happy with the device and the software. Next step will be to install some ubuntu desktop applications using the information found here:

https://docs.ubports.com/en/latest/userguide/dailyuse/libertine.html

Anybody here knows which libertine container types are supported by ubuntu 15.04r3 on BQ M10 FHD?

Looking forward to replacing my aging firefox-os phone with some new phone running ubports.

cheers,

Dave

Hi @advocatux ,

I ran into the same "signature error", attempting to update my Aquaris 10 FHD tablet. As I don't mind breaking the tablet (as opposed to my phone), I just attempted to upgrade using the development channel, which worked (i.e. no signature error), then once that was running switched back to the stable image, and this time no signature error as well.

Working nicely now, no problems, some bugs I encountered with 15.04 seem to be fixed with that release. Very happy. Will attempt the same procedure on my phone.

Dave

@willemhexspoor Hi, seeing this question now, I was recently faced with a similar problem, having to use a Azure Active Directory cloud login, where the admins had forced users to configure MFA. Turns out that there is a well hidden way to configure a TOTP code-generator (i.e. google-authenticator) for use as second factor with Azure AD.

This was very frustrating, and I think that the MFA setup page uses dark patterns to prevent users from discovering that feature. There is not much information online.

After some googling I just found this old article that seems to describe the method. When the Azure login page tells you "Your organization requires more information bla bla" and you go to the setup page where it displays the QR code for windows authenticator, there will be some very misleading seemingly unimportant link (like "configure app without notifications") which will switch the whole authentication scheme to TOTP. Of course it will never tell you that it is using TOTP and the name Google Authenticator will not appear anywhere. Still it is TOTP and will work correctly using any "standard" authenticator app.

Hi @ubtouch-newbie , I'm also currently in the process of setting up a Volla phone under ubports. Just for clarity, can you describe the exact method by which you factory-reset your phone? Did you just do System Settings -> Reset or something more advanced? Asking just in case I encounter a similar problem. I've only verified working phone-calls and the wifi so far.

Dave

@flohack yes I had similar reservations which kept me from trying this. However, looking at the recipes documented here (i.e. mostly the shell script fragments by @chrisc and @c4pp4), this looks quite doable.

They're just encrypting /home/phablet. After reboot /home/phablet is non-encrypted. You run a shell-script to replace it with a dm-crypt encrypted loopback block device and restart the lightdm session. Still quite cumbersome, but still better than no encryption at all.

Maybe adding a launcher as described here for running the crypto-mount script in the terminal will make this more practical.

I'm not yet done setting this up, as I was set back by that Mediatek related dm-crypt bug in the kernel that ships on the Volla Phone. But no real show-stoppers so far.

So I accepted that I'll have to setup an encrypted home directory to have basic security.

This is not so simple on the Volla phone, due to kernel problems.

This thread has the ugly details.

Replying to myself, I started reading in the original Volla phone kernel sources. Looking at dm-crypt.c it seems that it has patches that add some very specific (and broken) hacks to accommodate Mediatek hardware encryption (everything that depends on CONFIG_MTK_HW_FD which is set on the Volla's phone kernel).

This function seems to be the culprit. It escapes me how anybody could throw this kind of hack into a production kernel:

/*
 * MTK PATCH:
 *
 * Get storage device type (for hw fde on/off decision)
 * or id (for crypt_config).
 *
 * Returns:
 *   0: Embedded storage, for example: eMMC or UFS.
 *   1: External storage, for example: SD card.
 *  -1: Unrecognizable storage.
 */
static int crypt_dev_id(const char *path)
{
	int type = -1;

	if (strstr(path, "bootdevice")) {

		/* example: /dev/block/platform/bootdevice/by-name/userdata */
		type = 0;

	} else if (strstr(path, "externdevice") || strstr(path, "vold")) {

		/* example: /dev/block/vold/private:179,2 */
		type = 1;
	}

	pr_info("[dm-crypt] dev path: %s, type: %d\n", path, type);

	return type;
}

So whenever you are trying to device-map some block device that does not have any of the substrings "bootdevice" or "vold" or "externdevice" in them, this returns -1, which in turn will break any attempts to use such a device in the device-mapper, thanks to the over-strict check added in crypt_ctr():

	cc->id = ret = crypt_dev_id(argv[3]);
	if (ret < 0)
		goto bad;

Note how e.g. any loop device /dev/loop* will thus fail. However, this also allows a workaround. We just use a different name (with the same major/minor device numbers) that matches 'externdevice'. This way dmsetup will magically start working:

cp -a "${LODEV}" /dev/externdevice1
echo "0 128 crypt aes-ecb 0123456789abcdef0123456789abcdef 0 /dev/externdevice1 0" |  dmsetup create crypt2

However, I am not sure whether this kind of workaround could be applied to 'cryptsetup'.

This really destroys any illusion WRT to code-quality of the kernels that is running the Volla phone.

Hi,

I've been unsuccessfully trying to encrypt parts of the home directory on my phone. It seems that device-mapper crypto is not working on the Volla phone, albeit the kernel looking like having the rudimentary dm-crypt support compiled in.

I started with example commands from this post, and then tried to get to the root of the problem by using lower level APIs. cryptsetup does not work at all. I'm now playing with dmsetup, as that allows more low-level interfacing to the device-mapper.

I would expect, that the following commands would create a very minmal (and unsecure) device-mapper crypto mapping on my volla phone (running this via ssh, sudo -i):

dd if=/dev/zero of=/home/phablet.img bs=1024 count=128 conv=excl
LODEV=$(losetup --find --show -r /home/phablet.img)
echo "0 128 crypt aes-ecb 0123456789abcdef0123456789abcdef 0 $LODEV 0" |  dmsetup create crypt2

However dmsetup fails with error:

 device-mapper: reload ioctl on crypt2 failed: Operation not permitted

Using strace to look at the root cause, it fails at ioctl

ioctl(3, DM_TABLE_LOAD, 0x607b2412e0)   = -1 EPERM (Operation not permitted)

If I use target "linear" instead of target "crypt", dmsetup does work, so the device-mapper and dmsetup are not totally broken.

The kernel on Volla phone is:

Linux ubuntu-phablet 4.4.146+ #47 SMP PREEMPT Mon Mar 8 05:16:13 CET 2021 aarch64 aarch64 aarch64 GNU/Linux

According to /proc/config.gz, it does have the relevant options enabled:

CONFIG_DM_CRYPT=y
CONFIG_CRYPTO_AES=y

What am I missing? The commands above work flawlessly on my Debian desktop PC. Anybody knows what other kernel options are required to make dm-crypt work? Is /proc/config.gz maybe lying about how the kernel was actually compiled? Is this a problem about user-space dmsetup not being compatible with the kernel in question?

cheers,

Dave

Replying to myself: I think I asked a similar question in 2019 WRT a Google Nexus 5 phone. Re-reading those answers now, it seems like any security depends on the ability to "oem lock" the boot-loader. Is something like that possible for the Volla Phone? Unfortunately there does not seem to be much public documentation available about Volla phone internals, also I'm not at all knowledgeable about that topic...

Hi,

just got a Volla Phone with ubports pre-installed and now in the process of setting it up (migrating from an older aquaris 4.5 phone).

Any advise on how to improve security against data being read from the phone when it is stolen? My concern is mostly about cached emails in dekko, address book, photos.

There is no micro-SD card installed, everything is on the local flash. Screenlock PIN configured.

How easy is it for an attacker to read from the internal flash? Developer-Options (adb etc.) seem to be disabled, and AFAICS the fastboot boot-loader does not directly allow data being read from the device? What would be the usual ways to retrieve data? By pushing some data-grabbing program via fastboot? How can that be hindered? Is it possible to lock or password-protect the fastboot boot-loader?

thanks for any hints,
cheers,

Dave

Hi,

I'm in the process of setting up a Google Nexus 5 with ubports for somebody else. And I keep wondering, what are the security implications of running ubports on a device with unlocked boot-loader?

In case the phone is lost or stolen, will any new "owner" of the device be able to access the WiFi passwords, IMAP passwords and all data, photos etc. stored on the phone by just connecting USB cable and running adb/fastboot to dump the flash?

Are passwords stored on the device encrypted with the unlock passcode?

What precautions can/should be done to secure the data on a phone running ubports?

Thanks for any insights,
cheers,

Dave

Hi @advocatux ,

I ran into the same "signature error", attempting to update my Aquaris 10 FHD tablet. As I don't mind breaking the tablet (as opposed to my phone), I just attempted to upgrade using the development channel, which worked (i.e. no signature error), then once that was running switched back to the stable image, and this time no signature error as well.

Working nicely now, no problems, some bugs I encountered with 15.04 seem to be fixed with that release. Very happy. Will attempt the same procedure on my phone.

Dave