Security on UT

arubislander

I don't think you can uninstall Morph browser. It comes bundled as a .deb in the root filesystem.

A Former User

@arubislander I was thinking the same...

Keneda

I don't think you can uninstall Morph browser. It comes bundled as a .deb in the root filesystem.

Ohhhhh, with a little R/W on the rootfs using UT³ and a little of command line magic, you'd probably can uninstall it, but i don't think that would be a good idea

AppLee

@C0n57an71n
To answer the why push Telegram instead of Signal ?

There is not really a push. The choice of Telegram was made because people used this platform and it was possible to port it to UT.
That was a choice by opportunity.
Signal is also ported to UT but has less users. The more users, the more interest and the more developers you get...

A Former User

@AppLee Always the chicken and egg problem, ain't so?!...

Moem

@C0n57an71n said in Security on UT:

@Keneda yes, telegram is open source, but not what whappens in the servers. That is why Axolotl should be pushed forrward.

The two aren't interchangeable. It also depends on whether any of your contacts use it. I happen to use both, for that reason.
I'm eagerly awaiting the further development of Axolotl, but it will not replace Tg for me.

dobey

@AppLee Also, with respect to this, people were already using Telegram for group chats (which I think Signal didn't support yet back then), and Matrix was nowhere near usable in ~2015 either.

Telegram and Canonical also had some agreement back in the day, which led to the creation of the old Telegram app on UT.

So less of a push and more of just the way things were at the time, and now we have those.

trainailleur

@C0n57an71n said in Security on UT:

@kugiigi said in Security on UT:

However, there's no support yet for encryption and such so your device is vulnerable when someone else gets a hold of it.

@kugiigi That applies everywhere: don't let your stuff be accessed by people you don't trust :))

Even people who are careful not to lose or misplace things cannot guarantee that their phone won't be stolen.

If a modern Iphone or Android is lost or stolen, no one is getting your data off it without a great deal of time, expense, and trouble.

Ubuntu Touch has unencrypted data and adb always on in recovery, so anyone who knows the adb command is going to extract your data quite easily.

Ubuntu Touch is a promising OS and is taking huge strides thanks to the devotion a great group of developers, but I feel that celebrating it for what it is not yet (secure, or any more private than a de-Googled Android phone with carefully selected apps) detracts from celebrating what it is.

domubpkm

With UT, developers and all users oscillate between hopes and frustrations: the former for what they would like to develop but don't can easily for various reasons, the latter for what they hope to get one day but without any guarantee: concerning a secure phone from A to Z, we are well in the case !

dobey

@trainailleur said in Security on UT:

Ubuntu Touch has unencrypted data and adb always on in recovery, so anyone who knows the adb command is going to extract your data quite easily.

Even if adb was off, the bootloader cannot be re-locked either, so one could simply flash TWRP and use adb with it instead.

And even if it had FDE today, using dm-crypt, the key and data would be stored on the same media, so combined with the previously mentioned lack of lockable bootloader, an attacker could just copy the wrapped key and image data off the device, and brute force decryption externally.

trainailleur

@dobey said in Security on UT:

Even if adb was off, the bootloader cannot be re-locked either, so one could simply flash TWRP and use adb with it instead.

Yes, I first tried this once, long ago, when I was curious how readable the Android-based UT devices were. It was only later that I realized the stock recovery had it enabled too.

And even if it had FDE today, using dm-crypt, the key and data would be stored on the same media, so combined with the previously mentioned lack of lockable bootloader, an attacker could just copy the wrapped key and image data off the device, and brute force decryption externally.

Indeed. Hence the general recommendation for extremely long and complex LUKS passphrases these days.

dobey

@trainailleur said in Security on UT:

Indeed. Hence the general recommendation for extremely long and complex LUKS passphrases these days.

Yes, which absolutely nobody ever wants to have to actually remember with their brain or type on a phone screen.

There's a reason that storing the key on separate media (hardware backed encryption keys in android) and avoiding extraneous user interaction is preferred by both Android and iOS now.

trainailleur

@dobey said in Security on UT:

Yes, which absolutely nobody ever wants to have to actually remember with their brain or type on a phone screen.

There's a reason that storing the key on separate media (hardware backed encryption keys in android) and avoiding extraneous user interaction is preferred by both Android and iOS now.

Correct Horse Battery Staple is a good start, and its entropy can be improved on considerably whilst still remaining memorable. That's something I can live with in the absence of perfection.

A Former User

@dobey Before I start writting this post I did some reading.
https://sensorstechforum.com/ubuntu-touch-os-is-it-secure-enough-and-should-you-use-it/
It is from 2016.
So today, the biggest issue is with adb and the bootloader, as far I understand.
How did the things changed from 2016 ? Would the PinePhone make a change regarding this?

A Former User

@trainailleur So the biggest concern is if someone get fizical access to the device? I understood right?

arubislander

@C0n57an71n said in Security on UT:

@dobey Before I start writting this post I did some reading.
https://sensorstechforum.com/ubuntu-touch-os-is-it-secure-enough-and-should-you-use-it/
It is from 2016.
So today, the biggest issue is with adb and the bootloader, as far I understand.
How did the things changed from 2016 ? Would the PinePhone make a change regarding this?

That article didn't make much sense to me to be honest. The security issues it mentioned were either not limited to or able to be mitigated by the phone OS, or not clearly explained why they were seen to be security issues.

dobey

@C0n57an71n I don't think that accurately applies to UT, and honestly I'd never seen it before anyway.

dobey

@trainailleur That may be true, but having to type that every time you pick up your phone to do something is going to become very tiring, very quickly. It's also going to be easy to make a mistake while typing, and with proper measures to prevent brute force attacks, could lead to loss of data; while at the same time, not preventing the copying of key/data off to attack with much more powerful hardware.

dobey

@C0n57an71n said in Security on UT:

@trainailleur So the biggest concern is if someone get fizical access to the device? I understood right?

Yes. The point of encrypting the storage, is to protect data when the attack has gained physical access.

trainailleur

@dobey said in Security on UT:

@trainailleur That may be true, but having to type that every time you pick up your phone to do something is going to become very tiring, very quickly. It's also going to be easy to make a mistake while typing, and with proper measures to prevent brute force attacks, could lead to loss of data; while at the same time, not preventing the copying of key/data off to attack with much more powerful hardware.

No, as typically implemented by Linux distros (including Ubuntu), you only type a luks passphase once between boots, prior to the mounting of the filesystem it contains. Your login and screen unlock passwords can be as long or short as you want them to be. The idea is that a running system should be cagey enough to resist a break-in but that a non-running system - at least on legacy hardware - has very little to protect it. The situation of legacy PC hardware is somewhat analogous to phones with unlocked bootloaders. Postmarket's osk-sdl is a small onscreen keyboard to serve exactly this purpose. (It looks like it is slated for their Community Edition PinePhone, incidentally.)

Yes, a running or even non-running system that is captured could be subject to a cold-boot attack and memory dump, but that is far from 100% reliable, and filesystem encryption remains a high barrier to intrusion.