I am trying to know if I can get root privileges with a system app to execute commands.
In this code:
getApplicationInfo().uid
In the documentation I can read that the uid is the kernel user-ID that has been assigned to this application; currently this is not a unique ID (multiple applications can have the same uid).
But how is this assigned?,
And the uid assigned to system apps,
does it has more privileges than normal apps to execute commands?
For all practical purposes, your Application's process will never be executing as uid=0 or root, as it has irreversibly changed to an ordinary user ID before a single line of code written by you executes.
When people make "root" apps, they are not changing the application process itself back to root - that is simply not possible. Instead, what they are doing is executing a new helper process which runs as root. Underneath the java level, this is ultimately done by calling an exec() family function on a file which has the setuid bit set. This file might either be the helper program itself, or more commonly it is a "root shim" such as a hacked "su" which in turn runs the specified helper program as root. Such a helper program is almost always native code, and is probably not registered with the Android framework to be able to utilize Android-level functionality.
System Applications do not run as root either. What they have that third party apps do not is special Android-level Permissions which cause platform services that do run as root or other privileged user id's to privileged things on their behalf. A few android permissions can also confer membership in user groups which have special access - some of these are available to third party apps (Internet permission for example) and some are not.
Basically, (I am not delving into the entire Linux explanation about uids. It can be easily found if you are interested). The uid in android is comprised of 2 parameters:
Application id
User id
The formula is this:
uid = app_id+100,000 * user_id
app_id is basically a random number (not REALLY random, but is different from device to device) that is assigned ti each application and the user_id, which is used on tablets running JellyBean, is assigned per user on the device (users are assigned a number starting user 0 , user 1, ...user n - for every new user defined on the device).
Applications can share an id as explained here: http://developer.android.com/guide/topics/manifest/manifest-element.html
Of course an app can't have the same uid for two different users, but the same app can have the same uid as another app the same user possesses.
System apps run are the only apps that may actually have access to services that other users may not have access to. They are located on the device under /system.
In order to write a system application you need to download the AOSP from Google, and compile it yourself with your app included.
Related
Does anyone know what is the behavior in production of a device-owner App, distributed thru Google Play, when updates occur?
As we know, installing a device-owner App involves some motivation and is not easy: reset to factory default then NFC-provision the device with a second device etc… So even if we consider this step done, would any further update involve so much pain, each time?
This question occurs because on my development device, I cannot re-launch the device-owner App with changes if it was previously installed… unless I reset the device to factory settings!
Thanks for reading…
Once your Device Owner app is set, a new file is created under /data/system/device_owner.xml that references the Device/Profile owner apps.
The Android system is then reading this file to check which application is considered as Device Owner or Profile Owner App.
This file contains refers to the applications by using their package name. Updating these apps won't infer on this file since the package name stays the same.
When you're updating your app, just make sure you're always using the same certificate as the one you previously used when first setting you device owner for the first time (which is a standard rule of security for every application update in Android anyway).
Permissions can also be updated the same way, without the need to reprovision it through NFC, nor dpm tool.
I'm having trobule trying to create a custom file access logger for Android. I've check FileObsever but I need to get the PID (USERID would be useful also) of the process that had access to a certain list of files.
I've also tried different options but with no success.
Is is possible to log with PID accessed certain file?
Regards!
There's been some discussion of adding PID reporting to the Linux inotify() mechanism (which is what FileObserver is presumably based on), but I'm not finding out from initial searches if that was actually merged and thus inherited by Android - and if it was, it would likely only work for foreign UID's for a monitor with administrative privileges.
You could try the FileObserver and then immitate lsof by scanning through /proc for fd's, to whatever (limited?) extent you'd be allowed to do so on Android. This would however give you race condition issues - the file could be closed again before you saw "who done it".
Likely if you really want to do this, you'll need a custom ROM - you could apply any necessary patches to inotify and either bless your security app with permissions or (if you prefer to be that way) disable the permission checks on reporting.
What I found about the patch - current merge status unknown:
http://lwn.net/Articles/307536/
Intro to direct use of inotify() (without the PID reporting):
http://www.linuxjournal.com/article/8478?page=0,0
This question has been asked before at How does Android enforce permissions?. While the discussions there are good, the question is still not fully answered.
In the development environment, exceptions are thrown when the app tries to do something that requires permissions not declared in AndroidManifest.xml. So how does the run-time system implement the run-time checking?
I guess it's most likely done in the core framework, which may or may not need support from native code. But I don't know what source code files in AOSP are relevant to this.
Android uses a lot of the standard Linux(-kernel?) mechanisms especially when it comes to hardware restrictions.
Every app gets assigned a new unique (Linux-)user id and whenever the app process is created the system creates it with that user id. The id will never change unless you remove the app. That means for accessing the lower system levels your app will appear as a certain user and every (Linux-)permission system that works with users will also apply to your app.
If you request WRITE_EXTERNAL_STORAGE in the manifest your app will also become member of the (Linux-)group (called sdcard_rw) that has permissions to write to that storage. Permissions on the filesystem are enforced to only allow writing to the system user (=owner) and the sdcard_rw group, anyone else (=other) may only read. See also Is Google blocking apps writing to SD cards
By doing that Android has to do pretty much nothing except for setting the correct UID/GIDs of the processes it spawns once the app starts and the rest is handled at lower levels. Apps that are not member of a certain group simply don't get access to certain hardware.
List of permission <> group mappings: platform.xml
There are also some (Android software) restrictions that are based on either the signature of your app and / or simply by looking up the permissions your app requested: e.g. ContextImpl#checkPermission() - but those permissions have to be checked at every entrypoint to code that allows restricted actions.
From time to time people discover ways to e.g. turn on GPS programmatically because a check like that is missing somewhere.
With regard to your second paragraph, "exceptions" are runtime faults. Permissions are not enforced at build time, only at run time.
Accessing hardware, low level operating system resources, and system files generally requires the app userid to be a member of an appropriate group which it may be assigned by the package manager as a result of having a corresponding android permission. (Familiar examples of that would be network sockets, and the sdcard write which zapl mentioned, but also system-only things like talking directly to the GSM modem or reading the raw touchscreen coordinates).
For the majority of android operations that are done by way of calling library functions which are stubs for interprocess communication to services running in a different process, the platform code running in the more privileged process on the receiving end of the ipc request checks with the package manager to find out if the calling application has the necessary android permission.
Many special permissions are only available to apps signed with the system signature - even if another app claims those in its manifest, they will not be applied by the package manager.
I'm new in Android. I have an Idea to enrich user's knowledge whilst installing a desired application.
the idea is developing an application that can analyze .apk file of the application to check if it's over-privileged or not. and inform the user if this application which he's trying to install is over-privileged or not.
but since there's already a mechanism from Android which asks user's consent to grant whatever permission the application requests, I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it or it can not.
I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it
None of these are possible, sorry. You are welcome to create your own custom firmware that has this feature, but you cannot create this capability via an SDK application, for obvious security reasons.
I am not far from where you are ~ the entire mechanization you seek is based on an xml file in the "root" of the installation - it is called AndroidManifest.xml = all permission based issues should begin original first efforts on that file:
The AndroidManifest.xml File
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following: .....
the "app-store" web based distribution system is supposed to pick that up and not only make some decisions on what to present to the user but as well differentiate to some extent what to do in the matter but as I just got a Droid-X emulator available in my installation I can tell you for a fact that "versioning" is subject to oversimplification as we cannot rely on users being tech-geeks
This is a theoretical situation:
I am writing an app to detect the presence of another on the phone
The classpath, name, Activity names etc. of the target app have been randomized, I can't just check if it's there (it is semantically the same but syntactically unique)
I have root access to the phone
The app is open source, and (apart from the package name and application name) I know everything about it.
The app generates no Log output.
I've been thinking of ways to detect whether this other app is present on the phone (assuming it is actually run from time to time), are the following methods feasible at all?
Look periodically for the presence of certain classes in memory
Search for known chunks of the compiled code in each installed apk
Detect the app running by inspecting the memory of the device at certain intervals and look for usage patterns matching the app
Are there any other ways of detecting another app under these circumstances?
Use PackageManager. It has a method returning info about all the apps, installed on the system: getInstalledPackages().