Posts made by 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

@advocatux , yes that makes sense. However, what's the recommended way to upgrade to 16.04 stable, in spite of the signature error I get?

Hi,

running an ubports installation on LGE Nexus 5, "stable" channel ( 15.04 r3).

The download of the new stable image under "System Settings" -> "Updates" fails with :

Update failed
SignatureErorr:
sig path : 060f5c1283d44... /android/cache/recovery/device-f43cba6c627...
[..]
keyrings: ['56b9554d8355b87653425cb..'] ['/var/lib/system-image/keyrings/image-signing.tar.xz']

[..]

If I switch to the development channel, I do get a successful download (but don't want to install development version on my phone). If I switch back to stable, the download restarts and fails with the same error.

Any idea what's broken? Is this a local or server-side problem?

cheers,

David

Yes, I retried, the "stable", channel download (Versiwon 3) reproducibly fails with an "Signature Error". The development channel download (Verison 287) works and offers an "Install..." button once done.

Maybe will add another forum topic about the signature error.

Dave

@Lakotaubp ,

just switched channels to development and back to stable. It then started downloading an image. Though finally it failed "Update failed,; signatureError: ...".

Will retry again later and if this can't be made to work, commence with the manual upgrade procedure you linked.

thanks,

Dave

Hi,

I installed my Nexus 5 with ubports more than a year ago. According to "System Settings" -> "About" it is running Ubuntu 15.04 (r3), stating "Last updated "1/3/70" (which maybe means "never").

Pressing "check for updates" says "Software is up to date".

However, on devices.ubuntu-touch.io latest stable version is listed as 16.04.

In "channel settings" I have selected "Stable". I see no way to request the upgrade to 16.04.

Any ideas on how to get my installation up-to-date?

Thanks and cheers,

Dave

see also

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

So this is where my flash memory is going:

$ mount|grep mmcblk0p23 | sed -n -e 's/.*on \([^ ]\+\).*/\1/p'|sudo xargs du --max-depth=2 -c -h

-> /userdata/system.img is taking 2 GB and seems to be the actual ubuntu touch file system image. Then I wonder why there is another 4 GB partition in /dev/mmcblk0p21. This is mounted on /android/cache. Is there any reason for that "cache" partition taking up so much memory? Can its size be changed during installation from the ubports-installer to leave more room for my home partition?

@advocatux my profile was still empty by the time you wrote your reply. sorry for wasting your time

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