FORUMS
Remove All Ads from XDA

[DEV GUIDE][2016.12.22] How-To SU

11,217 posts
Thanks Meter: 86,000
 
By Chainfire, XDA Ad-Free Senior Moderator / Senior Recognized Developer - Where is my shirt? on 29th October 2012, 08:38 PM
Post Reply Email Thread
14th April 2016, 11:49 PM |#101  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,000
 
Donate to Me
More
Quote:
Originally Posted by Catalyst06

...

Any audit logs from dmesg, logcat, or /data/misc/audit ?
 
 
14th April 2016, 11:51 PM |#102  
Senior Member
Thanks Meter: 218
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Any audit logs from dmesg, logcat, or /data/misc/audit ?

Yes. Please check the post again. I've added the audit logs recently.
14th April 2016, 11:57 PM |#103  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,000
 
Donate to Me
More
Quote:
Originally Posted by Catalyst06

Yes. Please check the post again. I've added the audit logs recently.

Try "attradd { uhid_device input_device } { mlstrustedsubject mlstrustedobject }". Not quite sure about this one.
14th April 2016, 11:59 PM |#104  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,000
 
Donate to Me
More
Quote:
Originally Posted by Catalyst06

Yes. Please check the post again. I've added the audit logs recently.

Note of course that a better solution would be running whatever handles this input as root, and have it communicate with your main app over sockets and pipes, rather than adjusting security settings for all appdomain/untrusted_app.
15th April 2016, 12:31 AM |#105  
Senior Member
Thanks Meter: 218
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Try "attradd { uhid_device input_device } { mlstrustedsubject mlstrustedobject }". Not quite sure about this one.

Sorry for taking long to test. While the policies are patched successfully. It unfortunately doesn't make a difference. As the uinput module still remains inaccessible.

I actually tried it with another device on Lollipop just to make sure there isn't any problem with my code. On Lollipop the Virtual Touch Screen creation was successful and everything worked the way it should've. Thanks for trying to help. Is there anything else we can do? The lack of audit messages aren't helping either.

---------- Post added at 04:52 AM ---------- Previous post was at 04:48 AM ----------

Quote:
Originally Posted by Chainfire

Note of course that a better solution would be running whatever handles this input as root, and have it communicate with your main app over sockets and pipes, rather than adjusting security settings for all appdomain/untrusted_app.

Yes I understand that. It was a bad design decision. Choosing to use JNI libraries.

It'll be great if you could provide any solution to my current issue. If nothing works out unfortunately I will probably have to rewrite most parts of the app. Thanks again though.

---------- Post added at 05:01 AM ---------- Previous post was at 04:52 AM ----------

I also noticed something new in the audit logs in Marshmallow. Something like this " untrusted_app:s0:c512,c768 " . Does this signify anything new?
17th April 2016, 11:41 PM |#106  
Senior Member
Thanks Meter: 218
 
Donate to Me
More
Hello @Chainfire, I've tried to do a bit of research regarding my issue. The problem as it seems is that I'm using JNI Library instead of JNI Executable.

Had I used JNI Executable I could have spawned it through my app from SU shell and could've changed it's context. But I'm using JNI Library and use an interface to call C/C++ functions via Java.

This way the library is loaded by the app and uses the app's context. Which is untrusted:s0. Even with Root access my Application's context doesn't change to init:s0. Only the supersu shell has init:s0 context.

Is there anyway we could change the context of my App to init:s0 or maybe system_app:s0? This might solve my issue I believe. I would really appreciate if you could help me with this, the one last time.

Thanks again.
18th April 2016, 09:19 AM |#107  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,000
 
Donate to Me
More
Quote:
Originally Posted by Catalyst06

I also noticed something new in the audit logs in Marshmallow. Something like this " untrusted_app:s0:c512,c768 " . Does this signify anything new?

Yes, it's called MLS/MCS. This is why I asked you try mlstrustedobject / mlstrustedsubject. It's a tricky subject and annoying to work with.

http://selinuxproject.org/page/NB_MLS

Quote:
Originally Posted by Catalyst06

This way the library is loaded by the app and uses the app's context. Which is untrusted:s0. Even with Root access my Application's context doesn't change to init:s0. Only the supersu shell has init:s0 context.

Is there anyway we could change the context of my App to init:s0 or maybe system_app:s0? This might solve my issue I believe. I would really appreciate if you could help me with this, the one last time.

Unfortunately that is not currently possible.
20th April 2016, 09:46 PM |#108  
Senior Member
Thanks Meter: 218
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Yes, it's called MLS/MCS. This is why I asked you try mlstrustedobject / mlstrustedsubject. It's a tricky subject and annoying to work with.

http://selinuxproject.org/page/NB_MLS



Unfortunately that is not currently possible.

Nevermind. Thanks a lot for your time.
16th May 2016, 12:28 PM |#109  
ssrij's Avatar
Senior Member
Flag Oxford
Thanks Meter: 1,860
 
Donate to Me
More
I am in a weird situation. I have an app that requires root to function. I am using libsuperuser and calling the available() function in a background task, but I have some of users report me that (1) they didn't see the SU authorisation prompt AND the app received root permission or (2) The app didn't make SU show the authorisation prompt, so they couldn't approve the app. On my phone (using latest SuperSU beta), and on many other people's phones, it works fine, but on some, it does that.

Any idea why this could happen and what can be done to fix this? This is how I call available():

Code:
Tasks.executeInBackground(MainActivity.this, new BackgroundWork<Boolean>() {
                @Override
                public Boolean doInBackground() throws Exception {
                    return Shell.SU.available();
                }
            }, new Completion<Boolean>() {
                @Override
                public void onSuccess(Context context, Boolean result) {
                    isSuAvailable = result;
                    Log.i(TAG, "SU available: " + Boolean.toString(result));
                    if (isSuAvailable) {
                        // Perform stuff
                        }
                    } else {
                        Log.i(TAG, "SU permission denied or not available");
                        // Show error dialog
                    }
                }
17th May 2016, 08:33 AM |#110  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,000
 
Donate to Me
More
Quote:
Originally Posted by ssrij

I have some of users report me that (1) they didn't see the SU authorisation prompt AND the app received root permission or (2) The app didn't make SU show the authorisation prompt, so they couldn't approve the app

Which su are they running?

On various CM-based firmwares you do not get a confirmation dialog, you need to manually enable root access before starting the app.
17th May 2016, 08:40 AM |#111  
ssrij's Avatar
Senior Member
Flag Oxford
Thanks Meter: 1,860
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

Which su are they running?

On various CM-based firmwares you do not get a confirmation dialog, you need to manually enable root access before starting the app.

I'm not sure, I haven't asked them, although some of them said they're on the latest SuperSU stable or KingRoot. I'm on SuperSU beta (May 10) on a Galaxy S7 edge, and I see a prompt.

Is there a way to handle external authorisation? A way to detect if the SU authorisation dialog will show up or not, so I can tell the user to manually grant access via their SU app.

Sent from my Samsung Galaxy S7 Edge using XDA Labs
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes