Related
Since there have been so many security discussions going on for Android and iPhone, I did a short post on the topic comparing the security models of both. Do chime in with your comments all
Android vs iPhone: Security Models
One point about the "sandbox".
You already pointed out that Apple doesn't have "permissions", but that also affects the sandbox. An app doesn't have to ask permission to get your personal data and they would have no way of stopping it even if it did.
Android not only requires the app to ask for the permission when you install it, they can also enforce that restriction if the permission wasn't requested. The Android sandbox does not allow code to do things it never advertised because it is running tightly controlled bytecodes that can be statically proven to only access the information it was given permission to access.
On the contrary, iOS apps can run any code without any controls other than what the reviewer observes.
So, the "permissions" and the tighter control of the Android sandbox combine to make the apps even more tightly restricted.
One thing I would love to see added to Android is the Blackberry style of permissions where each request can be set to "allow, ask each time, disallow" so you can disallow an app from using a permission it requested, or even allow it, but require the OS to ask you to verify each time the app uses that capability. Right now Android says "this is what it *WILL* do and if you install it I won't do anything to restrict it - either accept this or don't install the app" which is very limiting.
There are quite a few apps that I've installed which asked for permissions that it isn't important for me to give them. I want to use their main feature, but the programmer went and added what they thought was a nifty unrelated feature and that secondary feature requires permissions. If I only want the main feature then I should be able to disallow the unnecessary "addon" permissions. (To name an example - a Zip file browsing app that wants to kill tasks? Really? Why? Oh, because the developer thought it was cool to add a task killer to every app in the market. D'oh!)
Also, the lack of this per-permission "line item veto" capability is teaching Android users to just blindly accept an apps permission requests because they all sound daunting even for benign apps and so they learn to stop thinking about it and the permission granting is really just noise for the sheep for the most part. Granted, there are a few security conscious users that will push back when apps request permissions outside of their needs, but it would be better if the average user would see every time an app does something suspicious, rather than just letting it happen willy-nilly under the covers and the security conscious would have better tools to investigate their suspicions by verifying that the app only generally does use the capabilities when it is about to do something worthwhile.
^^ I totally agree with what you say.. And the ability to revoke certain permissions from the app at certain times is what i desire as well. .This is something that always makes me doubtful when installing apps.. They should atleast do this for the internet permission. I know I can do this by rooting my phone but I want to be able to do it without rooting...
Just a heads up, somehow someone compromised my account, and was able to deactivate my phone, and activate their own EVO on my account, change plans, and change all the security info, PIN security question, and security email. A bit of a wakeup call, running rooted phones, installing apps that give themselves unfettered access...
Yes, "its your own damn fault", but whatever, just keep your eyes constantly peeled, and make sure your sprint "myaccount" settings are secure...
What ROM where you using? Any idea what apps you had installed that might have been compromising your data?
Take some screenshots of all your installed apps. Couldn't hurt.
This is more of a Sprint thing. They have a problem with internal fraud
Was using CM6 at the time. According to the rep I spoke with (that actually helped me, the first guy was a turd), they had been calling in between the 28th and 30th, on the 30th they were able to remove my device and add theirs.
I don't think it was any of the apps I have installed. I'm thinking it was either an inside job, or someone else (ie, haxor) on Sprint's nodes during the last week sniffing packets. Reason I think that is that they seemed to have compromised the security by way of changing the e-mail address that security updates go to. I don't know, its just a crappy feeling overall. Kind of like when I was mugged many years ago...
hondoslack said:
Was using CM6 at the time. According to the rep I spoke with (that actually helped me, the first guy was a turd), they had been calling in between the 28th and 30th, on the 30th they were able to remove my device and add theirs.
I don't think it was any of the apps I have installed. I'm thinking it was either an inside job, or someone else (ie, haxor) on Sprint's nodes during the last week sniffing packets. Reason I think that is that they seemed to have compromised the security by way of changing the e-mail address that security updates go to. I don't know, its just a crappy feeling overall. Kind of like when I was mugged many years ago...
Click to expand...
Click to collapse
Sprint should should just clone that account, deactivate it, ban the new ESN.
I fail to see the benefit of account jacking (especially after account owner's phone gets deactivated)
jerryparid said:
Sprint should should just clone that account, deactivate it, ban the new ESN.
I fail to see the benefit of account jacking (especially after account owner's phone gets deactivated)
Click to expand...
Click to collapse
I like what happens (and it rarely happens,Ive heard stories of things that have happened way back,which are always good for a chuckle) where I work when someone does something illegal,or commits crimes using sensitive information at work. The US Marshals come,drag them out in handcuffs for everyone to see and then they get their room and board on the US Government for the next few years.
Every phone is legally required to have GPS that is available at all times and it sounds like they are committing identity theft. Have the police, or if they are in a different state possibly FBI, go get them.
This was an inside job and has nothing to do with your ROM or the fact that you rooted your phone. Threads like this could easily scare people away from rooting for no good reason.
I think you might have gave someone your info!!
dallashigh said:
This was an inside job and has nothing to do with your ROM or the fact that you rooted your phone. Threads like this could easily scare people away from rooting for no good reason.
Click to expand...
Click to collapse
This may not have had anything to do with his phone being rooted but it is possible that could have had something to do with it too. When you root your phone you are effectively bypassing just about every single security feature put on there.
You are lying to yourself if you think rooting your phone doesn't make your information much easier to steal.
jahnile said:
This is a strange story, def.ly a wake up call.
http://WWW.rootznculture.com
Click to expand...
Click to collapse
NVM wrong thread
xHausx said:
This may not have had anything to do with his phone being rooted but it is possible that could have had something to do with it too. When you root your phone you are effectively bypassing just about every single security feature put on there.
You are lying to yourself if you think rooting your phone doesn't make your information much easier to steal.
Click to expand...
Click to collapse
That is patently false. If you install a custom ROM then you are trusting the ROM developer not to put anything sneaky in there. Considering CM6 is open-source and used by thousands of people, it's unlikely to be the ROM's fault.
An app with root can do just about anything. That is why the Superuser app is there to make sure only apps that need it can get root access.
Installing apps from non-Market sources is much riskier than rooting your phone. Installing an SSH daemon would make it possible to access your system remotely. That would also be a security risk.
Enabling USB debugging will make it easier for someone with physical access to your device to access your information. That much is true.
There is absolutely nothing about the act of rooting that puts your information in jeopardy.
dallashigh said:
That is patently false. If you install a custom ROM then you are trusting the ROM developer not to put anything sneaky in there. Considering CM6 is open-source and used by thousands of people, it's unlikely to be the ROM's fault.
An app with root can do just about anything. That is why the Superuser app is there to make sure only apps that need it can get root access.
Installing apps from non-Market sources is much riskier than rooting your phone. Installing an SSH daemon would make it possible to access your system remotely. That would also be a security risk.
Enabling USB debugging will make it easier for someone with physical access to your device to access your information. That much is true.
There is absolutely nothing about the act of rooting that puts your information in jeopardy.
Click to expand...
Click to collapse
You say any app with root can do just about anything, you just confirmed what I said. If whatever terminal app you are using can give you root(superuser) access without a password than any app can do it.
A SSH shell is for communicating over a network, it has nothing to do with root access.
If you read recently at defcon someone showed a market app that could root your phone without your permission and take some private info. So without root your screwed to. So you can probably blame an app before root. Also all data is encrypted so I doubt it was a packet sniffer.
This is a Sprint issue. I've seen and heard of it happening way too many times for me to assume that it's Android related even in the slightest bit.
I don't really think it's fair to lump rooting and basic modification in with account theft. There are always multiple sides to any story.
dallashigh said:
That is patently false. If you install a custom ROM then you are trusting the ROM developer not to put anything sneaky in there. Considering CM6 is open-source and used by thousands of people, it's unlikely to be the ROM's fault.
An app with root can do just about anything. That is why the Superuser app is there to make sure only apps that need it can get root access.
Installing apps from non-Market sources is much riskier than rooting your phone. Installing an SSH daemon would make it possible to access your system remotely. That would also be a security risk.
Enabling USB debugging will make it easier for someone with physical access to your device to access your information. That much is true.
There is absolutely nothing about the act of rooting that puts your information in jeopardy.
Click to expand...
Click to collapse
Then what is this article referring to? http://phandroid.com/2010/07/31/hackers-release-data-stealing-program-to-push-google-to-plug-holes-at-security-conference/
xHausx said:
You say any app with root can do just about anything, you just confirmed what I said. If whatever terminal app you are using can give you root(superuser) access without a password than any app can do it.
Click to expand...
Click to collapse
Sure you don't have to enter a password, but the first time the app runs, you DO have to confirm that you want to give it root access. And again that would be the APP that is malicious and not the mere fact that your phone is rooted.
xHausx said:
A SSH shell is for communicating over a network, it has nothing to do with root access.
Click to expand...
Click to collapse
I know what SSH is. I'm not an idiot. An SSH server is something that would actually put your device at risk of being remotely accessed without your knowledge or permission.
redrazr7791 said:
Then what is this article referring to? http://phandroid.com/2010/07/31/hackers-release-data-stealing-program-to-push-google-to-plug-holes-at-security-conference/
Click to expand...
Click to collapse
They distributed a trojan that installed malware at the same time it rooted your phone.
http://www.androidcentral.com/android-passwords-rooted-clear-text
Anyone else see this article? Any thoughts? Just curious what ppl smarter than me think...
Just don't download programs with root access that haven't been widely tested.
But if your phone gets stolen you could be screwed if the thief is savvy enough :X
Normally when I get a popup saying this app is asking for Root I know it and I allow it. However if I get something that isn't allowed of course I'm not going to allow it and more than likely delete it.
Thanks for bringing up the article too.
I think I only had two apps that ever required SU permission, but it's definitely something to think about until the encryption update comes.
that's what i thought. i've been a linux user for about 10 years now so the idea of rooting sounded pretty risky to me. of course i finally got the nerve to root and create my first nandroid about 10 minutes before finding that article...
i guess as long as i still have control over apps that request root access, i'll be fine. that was my main fear.
thanks!
WARNING: This is not a place for you to come to say how great you think Chainfire is. I'm not calling his character into question, only his methodologies and the character of the outfit he sold out to (and I don't question the act of selling out, that's business, pays the bills, and puts kids through college). The debates about what people prefer and why are as old as the first software. And of course, I will not tell you what to do, no matter how much I disagree with you. If you UNDERSTAND what I have to say, then THIS software is for you. If you don't, you are probably better off with binaries.
The root situation on Android 5.x left a lot to be desired. There was basically just one distributor of a functional substitute user command (su), and it was binary. Recently, ownership of that binary and all of its history has become the property of a previously unknown legal entity called "Coding Code Mobile Technology LLC". While it was presented as a positive thing that that entity has a great involvement with android root control, this is actually a VERY frightening development.
The people at CCMT are no strangers to the root community. They have invested in, or own, a number of popular root apps (though I am not at liberty to disclose which ones) - chances are, you are running one of them right now. I believe SuperSU has found a good home there, and trust time will not prove me wrong.
Click to expand...
Click to collapse
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
You don't know the owners, and they are distributing a binary, so who the heck knows WHAT is going on.
Now a few important considerations with respect to your security and privacy;
1) Obfuscated binary cannot be sanely audited.
2) Function of this binary depends on the ability to manipulate selinux policies on the fly, including RELOADING the policy altogether and replacing it with something possibly completely different. Frankly, I've never heard a single reason why this should be necessary.
3) While a root control application may give you nice audits over other software that is using its service, it can *EASILY* lie about what it is doing itself. It can delete logs, it can share root with other applications that they have made deals with, it can directly sell you out to spammers, etc.
That is WAY too dangerous, and not worth the risk.
Frankly, you are safer if you disable selinux AND nosuid, and just run the old style of root where you set a copy of sh as 6755. And that is FRIGHTENINGLY dangerous.
So not satisfied with this state of root, and especially now with a new unknown entity trying to control the world, we bring you the rebirth of the ORIGINAL Superuser:
https://github.com/phhusson/Superuser
https://github.com/lbdroid/AOSP-SU-PATCH (this one is mine)
From the history of THAT Superuser:
http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html
Yes, look at the Superuser repo above and see whose space it was forked from.
Note: This is a work in progress, but working VERY well.
Use my patch against AOSP to generate a new boot.img, which includes the su binary.
Features:
1) selinux ENFORCING,
2) sepolicy can NOT be reloaded.
3) It is NOT necessary (or recommended) to modify your system partition. You can run this with dm-verity!
The source code is all open for you to audit. We have a lot of plans for this, and welcome suggestions, bug reports, and patches.
UPDATE NOVEMBER 19: We have a new github organization to... "organize" contributions to all of the related projects. It is available at https://github.com/seSuperuser
UPDATE2 NOVEMBER 19: We have relicensed the code. All future contributions will now be protected under GPLv3.
*** Regarding the license change; according to both the FSF and the Apache Foundation, GPLv3 (but not GPLv2) is forward compatible with the Apache License 2.0, which is the license we are coming from. http://www.apache.org/licenses/GPL-compatibility.html . What this means, is that it is *ILLEGAL* for anyone to take any portion of the code that is contributed from this point onward, and use it in a closed source project. We do this in order to guarantee that this VITAL piece of software will remain available for EVERYONE in perpetuity.
Added binaries to my the repo at https://github.com/lbdroid/AOSP-SU-PATCH/tree/master/bin https://github.com/seSuperuser/AOSP-SU-PATCH/tree/master/bin
These are *TEST* binaries ONLY. Its pretty solid. If you're going to root, this is definitely the best way to do so.
The boot.img has dm-verity and forced crypto OFF.
The idea is NOT to use as daily driver, while I can make no warranties at all regarding the integrity of the software, I use it myself, as do others, and its pretty good.
What I would like, is to have a few lots of people try it out and report on whether things WORK, or NOT.
IF NOT, as many details as possible about what happened, in particular, the kernel audit "adb shell dmesg | grep audit". On non-*nix host platforms that lack the grep command, you'll probably have to have to add quotes like this in order to use android's grep: "adb shell 'dmesg | grep audit'".
How to try:
0) Starting with a CLEAN system.img, get rid of supersu and all of its tentacles if you have it installed, if it was there, it will invalidate the tests.
1) Install the Superuser.apk. Its just a regular untrusted android application. Yes, there is a security hole here, since we aren't (yet) authenticating the communications between the android application and the binaries, or validating the application by signature, or anything else that would prevent someone from writing a bad Superuser.apk. This is on the list of things to do.
2) fastboot flash boot shamu-6.0-boot.img
3) test everything you can think of to see if it works as expected.
Note: there are some significant visual glitches in the android application, but nothing that makes it unusable.[/quote] @craigacgomez has been working on fixing up the UI. Its really paying off!!!
How you can reproduce this YOURSELF, which we RECOMMEND if you feel like daily driving it (in addition, make sure that you UNDERSTAND everything it does before you decide to do that, you are responsible for yourself;
You can build it any way you like, but I do my android userspace work in eclipse, so that is what I'm going to reference. Import the project from phhusson's git, including SUBMODULES. Right click the Superuser project --> Android Tools --> add native support. The library name you choose is irrelevant, since it won't actually build that library. Right click project again --> Build configurations --> Build all. This will produce two binaries under "libs", placeholder (which we won't be using), and su. You need the su binary. Then right click project again --> run as --> android application. This will build Superuser.apk, install it, and launch it.
Next:
repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1
repo sync
Then apply su.patch from my git repo.
UNFORTUNATELY, the repo command isn't smart enough to apply a patch that it created itself. That means that you are going to have to split up the patch into the individual projects and apply them separately to the different repositories. This isn't that hard of a step though, since there are only FOUR repositories I've modified... build/ (this just makes it possible to build with a recent linux distro that doesn't have an old enough version of openjdk by using oraclejdk1.7. The boot.img doesn't actually need the jdk to install anyway -- its just part of the checking stage, so its up to you.), device/moto/shamu/, external/sepolicy/, system/core/.
After applying the patches, copy the su binary you generated with eclipse into device/moto/shamu/
Then ". build/envsetup.sh; lunch aosp_shamu-userdebug; make bootimage". That should take a minute or two to complete and you will have a boot.img built from source in out/target/product/shamu/
NEW UPDATE!!!!
While I haven't yet gotten around to running a complete cleanup (very important family stuff takes priority), I *HAVE* managed to find a half hour to get on with the Android-N program. If anybody takes a peek at the AOSP-SU-PATCH repository on the AOSP-N branch, you should find some interesting things there.
One warning first though... I updated the patches to apply against the N source code, and then updated some more to actually compile, and compiled it all. BUT HAVE NOT HAD THE OPPORTUNITY TO TEST IT YET.
Nice thing you came up. Sounds awesome.
We should have an alternate to all LLC thing, no matter how much respect (I owe you Chainfire thing) we got for the man who created CF Root (since Galaxy S days) and SupeeSU.
wow, tyvm for this! Will definitely test for ya and let you know.
I already applied your patch, built my own binaries and the boot.img but won't have a chance to test anything until tomorrow. Would love to get this %100 working fine and yeah, will use this from here on out instead of supersu.
Thanks again and yeah, will post when I have something ^^
I will be following progress closely, as should others. Without something like this, many in the community may naively let a corporate entity control root access on their devices. This is extremely frightening, it may not happen right away but if you believe the an entity will not monetize or exploit the current situation I believe you are sadly mistaken.
I could be wrong, however, it's not a risk I will take lightly and no one else should either.
Thanks for this.
Nice work!! Will be following this thread closely.
Time for me to learn eclipse. And do a heck of a lot more reading.
Larzzzz82 said:
Time for me to learn eclipse. And do a heck of a lot more reading.
Click to expand...
Click to collapse
Just note that I use eclipse because I'm used to it. Its become the "old" way for android dev.
i just paid for superSU is this the same people?
TheLoverMan said:
i just paid for superSU is this the same people?
Click to expand...
Click to collapse
I'm not sure what you are asking... are you asking if I am in any way affiliated with supersu, then you probably failed to read the first post in this thread altogether.
Charging money for a binary blob to use root on your device is borderline criminal, and unquestionably immoral. I'm sorry to hear that they got something out of you.
This is pretty great. I'll be watching this as well.
Perhaps this is not the place to take the tangent but why does root behave as it does and not more similar to a standard linux distro? It seems like it would be much more secure to have a sudo function as opposed to an all encompassing root. I'll admit I'm not that familiar with the inner working of the android OS but off hand I can't think of any program that absolutely needs to be automatically granted root every time it wants to run (I'm sure there are but even in this case the power user could chown it to standard root).
Wouldn't it be much more secure if you had to go in to developer options (which are already hidden by default) and turn on the option for sudo. This would then require a sudo-user password (perhaps even different than the standard lock screen password). Need to run a adblock update? Enter the password. Need to run Titanium backup? Enter the password... etc. Much more secure than a push of "accept".
Sorry for off topic but it's always made me wonder and seems like it would be root done right (see how I tied that back to the topic ) If elevating programs/tasks to a superuser was more secure perhaps it would not need to be such an issue...
^ Some root functionality is just too common for a Linux like sudo password to be usable at all. I'll give 2 examples:
1. Since Lollipop Google disabled access to mobile network settings for third party apps. Now it's only possible with root. I have an app that together with Tasker automates my network changing. That network app needs root access EVERY time there is any changes to the connected network and when it wants to change the settings.
Phone connects to a different cell tower? Root needed to detect this and determine the mobile network status.
You can figure how many times this is required per day.
2. I use Greenify to force some misbehaving apps to sleep after the screen goes off. It needs to request root every time it wants to sleep one of those apps. In other words every time I use them, after my screen goes off and I turn it back on I'd be facing both my secure lockscreen and the sudo password.
There's are plenty of other apps that need to request root access on a regular basis. These were just a few examples. If you only need root for TiBu then a sudo password type of security measure would work. In my case all I'd be doing with my phone would be typing that password again and again.
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Sent from my Nexus 6 using Tapatalk
Interesting thread. Thanks for your work....subscribed
doitright said:
There are precisely two motives I can imagine for buying up all the root control software for Android;
1) monetizing it, which is contrary to the user's best interests,
2) something very frightening and dangerous involving the potential exploitation of everybody's devices.
Click to expand...
Click to collapse
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
I've read a few articles suggesting that they would prefer to prevent people from rooting their phones (partially so that they can monetise Android Pay - which requires a Trusted Computer Base, which means unrooted - as well as controlling Ad Blockers, which affect a revenue stream). I also suspect that only a tiny minority of Android users - and most of them are probably on here - actually root their devices.
Regardless of the motives, having a technological monoculture is never a good thing, especially when it is delivered as a binary owned by an unknown organisation.
(No disrespect to Chainfire - I have had many years of root access to my devices thanks to his efforts.)
scryan said:
Beyond what is said above, to my understanding... What "root" is is just a way to install the "su" binary to your phone, with a nice GUI to make it more friendly for phone/tablet use.
Click to expand...
Click to collapse
Not quite.
"root" is the *name* of a privileged user, with user id of 0.
The "su" command (short for substitute user), is used to substitute your current user for another user, but most particularly root.
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Philip said:
I would suggest that there is a third potential motive here - that having control over the "only" way of rooting Android devices might be attractive to Google.
Click to expand...
Click to collapse
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
urrgevo said:
Being rooted, if memory serves, is being able to access and change any file in your root directory, at least that's a simplified way to see it. The SU app is a GUI that is mostly used to control the ability of apps to access and change the root directory.
Click to expand...
Click to collapse
Nope. The root directory can be setup to be accessible by specific users just by applying the appropriate permissions to the files.
The root directory and root user are not specifically related.
doitright said:
What does that have to do with the third party? I doubt very much that Google would appreciate the security of their users being compromised by a 3rd party.
Click to expand...
Click to collapse
Because the "third party" might actually be Google (or an organisation funded by them).
---------- Post added at 15:05 ---------- Previous post was at 15:02 ----------
doitright said:
Every application and many subsystems in Android are granted each their own user, which are very restrictive, hence the need to escalate to root to obtain necessary privileges.
Click to expand...
Click to collapse
Shouldn't need to su to root to do this - that's what setuid and setgid are for.
Evidently, BlackBerry will be heading straight to a 6 months on surviving root exploits which that is the same reason the device is being sold in the first place.
I knew some of my friends that are "conservatives" on Android and they believe that devices like Priv are the ones that makes Android not fun to deal with as root open big opportunity on having the best from a device.
I had been a faithful user of Google Nexus since Google Nexus 4 to 6 and yes and no I was in rush for a root, although I needed to control ads within the device, I am not a fan on modifying CPU's clock but controlling administrative aspect of the OS it is important too.
But BlackBerry Priv with a modified Android to be secure at least have answered all my needs that I sacrificed with the Google Nexus as previously was a faithful BlackBerry user and (you can correct me if I'm wrong) the bet pool for a fully functional root is currently at $300 and I wanted to ask if my friend are just being dramatic or it is true that not being able to root a phone can be upsetting to some?
BTW, I don't want to start a scuffle or anything, but I do believe BlackBerry has put many of know Android devs really to think about current exploits and if BlackBerry might be the precursor on a trend with other manufacturers.
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Good point and btw, that was one of the argument in the discussion, Google itself is a big data mining system itself.
Magissia said:
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Click to expand...
Click to collapse
Totally agree there - there has to be a secure way of providing root access to power users who know enough to request it and obviously accept the responsibility...
although i feel like the changes in the system you are proposing would probably mean that they wouldn't qualify for Google's android device approval process (whatever it's called) for allowing Google play services on it. That would basically defeat the purpose of moving to android as the app ecosystem is the main reason for the move...
Basically Google and apple are wielding all the power in the industry at this moment. and now with the (seemingly inevitable) slow, painful (especially for us fans) death of BlackBerry 10 on the horizon, i can't see there being an adequate alternative emerging for quite a while... unless you consider windows phone a viable alternative!! [emoji12]
So sit back, relax and enjoy our descent into the brave new world of 1984!!
Sent from my STV100-1 using Tapatalk
can't install a firewall. /thread if you think it's still secure.
well, you could still set up a VPN and filter on a remote server...
Sent from my STV100-1 using XDA-Developers mobile app