Beiträge von AA1973

Lösch meinen Beitrag. Die Büroklammer verschwindet, sobald man einen Beitrag editiert. Recht haste

Tapatalk > Wo, in welchem Forum?
Hier auf AP geht das "Bilder einfügen " auch nicht mit KitKat ...liegt wohl am Tapatalk Plugin, oder so ...

Edit. Das ist Quatsch....Asche über mein Haupt

https://play.google.com/store/apps/det…roid4batpercent

Gerade von Chainfire auf g+ veröffentlicht.

Zitat

On LPX13D, SELinux, and root

As promised, here are some more details about the current situation.

Why it breaks

Google has really put some effort into better securing Android, and we've seen a lot of SELinux related commits to the AOSP tree over the past months. There is some disconnect between the AOSP tree and actual L preview builds, some things from AOSP are not in the L preview build, and vice versa. Ultimately, it's a pretty good bet these things will mostly align, though.

On most devices and firmwares, SuperSU's daemon is started by the install-recovery.sh service script that runs at system boot time, as user root with the init context. This is what the daemon needs to function.

Recently, they've started requiring all started services to run in their own SELinux context, instead of init. Developers and security guys following AOSP have known this was coming; AOSP builds have been logging complaints about this specific service not having its own context for a while now.

Now this script runs as root, but as the install_recovery context, which breaks SuperSU's operation, as it is a very restrictive context.

In the last AOSP build I have tried (a few weeks old), there were a fair number of other holes that we could use to launch the daemon. At first glance(!), it seems those have all been closed. An impressive feat by the guys working on this, if it proves true.

How to fix it

To fix root, all that really had to be done was ensure the daemon's startup script is run at boot as the root user with the init context.

There are multiple ways to do this, but unfortunately for now it seems that it does require a modified kernel package (changing the ramdisk).

In the modified kernel packages I've posted for the Nexus 5 and Nexus 7, the daemon's startup is fixed by commenting out the line in init.rc that forces the install-recovery.sh script to run as the install_recovery context, so now it runs as init again, and all is well.

Repercussions

As stated above, it seems for now that modifications to the kernel package are required to have root, we cannot attain it with only modifications to the system partition.

Combine that with a locked bootloader (and optionally dm-verity) and a device becomes nigh unrootable - exactly as intended by the security guys.

Exploit-based roots are already harder to do thanks to SELinux, and now because of the kernel requirements for persistent root, these exploits will need to be run at every boot. Exploits that make the system unstable (as many do) are thus out as well.

Of course, this is all dependent on OEMs implementing everything exactly right. If a certain OEM doesn't protect one of their services correctly, then we can leverage that to launch the daemon without kernel modifications. While I'm fairly certain this will be the case for a bunch of devices and firmwares, especially the earlier L firmwares, this is not something you should expect or base decisions on. It is now thus more important than ever to buy unlocked devices if you want root.

It might also mean that every firmware update will require re-rooting, and OTA survival mode will be broken. For many (but far from all) devices we can probably automate patching the kernel package right in the SuperSU installer ZIP. We can try to keep it relatively easy, but updating stock firmwares while maintaining root is probably not going to work as easy and fast as it did until now.

Apps need updates

Unsurprisingly, with a new major Android release, apps will need updates. None more so than apps that go beyond the Android API, as root apps do, but even some non-root apps will be affected by the security changes.

As one example, someone posted in the SuperSU thread of a kernel flashing app that didn't work. From the logcat you could see that it was looking for partitions in /dev/block from its normal non-root user and non-init context. That used to be possible, but now it is restricted: normal apps no longer have read access there.

The solution for that app is actually quite simple: list the /dev/block contents using root instead. But simple solution or not, the app will still need to be updated.

By far most root apps should be updateable for L without too much issue. There are indeed exceptions that will need some special care, but those are rare.

Permissive vs enforcing

The kernel packages I posted for the Nexus 5 and 7 LPX13D firmware keep SELinux mostly set to enforcing. I say mostly, because SuperSU actually switches a small part of the system to permissive, so apps calling su can do most things without much interference. The details on this are lengthy (yes, your apps will be able to modify policies as well if needed, which should be rare), and I will document these for other developers after L retail release, assuming it will all still work at that time.

Alternatively, you can set the whole system to permissive or otherwise disable SELinux. There are other kernel packages released that indeed do this. The advantage here is that it instantly fixes some apps' issues, as the SELinux based restrictions have all gone the way of the dodo. The disadvantage here is that you've just shut down a major part of the security system of the device.

Some would argue that a device with an unlocked bootloader, root, encrypted modem firmwares of which nobody really knows what they're doing, etc, is inherently insecure, and thus disabling SELinux doesn't make much difference.

I personally disagree with this. While I do agree that these things weaken security down from the ideal level, I would still not disable more security features than I absolutely need to. Just because you cannot eliminate all attack vectors, is no reason to just completely give up on defending against them.

It is of course your own choice if you want to run a permissive system or not. I will strive to keep everything working in enforcing mode though, and I hope other root app developers will do the same - as stated earlier in the post, I believe this is still possible.

(everything in this post is subject to change for retail L release, obviously)

Alles anzeigen

Quelle:
https://plus.google.com/11351731947742…sts/VxjfYJnZAXP

http://de.samsung.com/de/news/read.a…7f-8c4a36d8a734
Der Download link hat sich geändert... MuggelPu kannst du den neuen link in den OP aufnehmen? Danke

P.S. hatte gerade das Nexus in der Hand als der Beitrag aufploppte :moustach::specs:

Hier im Umkreis von 500m habe ich auch entweder vollen Empfang bei LTE oder das dauerhafte Wechselspiel zwischen H, H+ und LTE (in der Wohnung). Hatte bei dir mal E-Plus gelesen, deswegen habe ich es erwähnt

Simple AOSP, neues Baseband, BASE (E-Plus), LTE geht, hier in FFM.
Ging aber auch gestern abend schon.

Hehe.
Frisch aus der MultiRom Recovery mit Materialised Beta Theme. Nutze es seit geraumer Weile. Einfach schick.

Du kannst auch via Volume Down und Power in der TWRP Recovery Screenshots erstellen.
[emoji12]

Bei weitem bin ich das nicht. Nur dieser Wakelock ging mir gehörig auf den Senkel... Hehe

Keinen blassen Schimmer. Was sagen denn Wakelock Detector oder Better Battery Stats, gibt es da irgendwelche Hinweise?

Bei mir haben sich bis gestern die Wearables und das Fitness Gedöns immer recht auffällig verhalten, seit dem letzten Play Services Update.
Das war der Wakelock bei mir

Zitat

com.google.android.gms.auth.be.proximity.authorization.userpresence.UserPresenceService

Nachdem ich die Wearables und Fitness Services (nahezu) allesamt via Disable Services APP eliminiert habe ist erst mal wieder Ruhe im Karton. Fitness wird überbewertet und Wearables ist das, was ich anziehe. Ohne Android. Also raus damit und gut ist...

Zudem habe ich das "prevent accidental wake-up" auch deaktiviert. In anderen Roms gab es häufiger das Problem, dass bei ankommenden Anrufen und Display Off es zu einer zeitlichen Verzögerung kam. Ist es mir nicht wert und der Akku läuft wieder normal.

P.S. Bin gerade auf ART und (aktuell) ohne Greenify...

Disable Service App
https://play.google.com/store/apps/det….disableservice

Wahrscheinlich nichts, da du das update und dieses Feature noch nicht drauf hattest. War nur ein Gedanke. Aber: warum auf nem alten Build hocken, wenn es schon ein update gibt?
[emoji41]
Hoffentlich kann dir der App Dev weiterhelfen.[emoji3]

Dann wird's aber Zeit ✌
Hehe

Einstellungen > Display > Prevent avcidental wake-up.
Neu in der v17.

Wenn du damit diese APP "all in one gestures" meinst, schreib doch bitte den Entwickler an. Bin gespannt auf seinen Lösungsvorschlag.

https://play.google.com/store/apps/det…ios.aiogestures

P.S. Hast du mal "prevent accidental wake-up" in display deaktiviert? Ist nur ein Gedanke.

Gesten in Nova funktionieren bei mir auch problemlos.

Was für Gesten meinst du? Steh gerade auf dem Schlauch

Anscheinend sind die builds gerade gestartet worden, zumindest ist das die Aussage im XDA Mako Thread. Vielleicht gibt es heute noch ein update... Schönen Feiertag noch.
[emoji106]

Und die Adresse des Entwicklers wird inzwischen auch angezeigt.

Nu denn. Glück auf hehe

Edit. Changelog Build 16 (aber auf github ist schon wieder einiges los...)

Zitat von snak3ater

Code

[B][COLOR="Red"]Build 16[/COLOR] Change log[/B]:


-  On-The-Spot: Add Gif support 
-  Update Pie QS Icons 
-  Update the volume panel color to match Hover 
-  Upstream Theme engine commits
-  Option to hide Adb notification icon
-  Battery light rework (Battery led colors can be configured now)
-  Settings: Use a seekbar preference to allow setting arbitrary animation scale values
-  Open app when clicking on icon in App Info screen 
-  Clock on lockscreen
-  ART: Picked up some commits from master
-  InCallUI: Tweak button background color value (Used black color for 'classic incoming call screen style')


-  [B]Kernel[/B]: Linux 3.4.104

Alles anzeigen

M.E. eher eine Providergeschichte.