I had earlier written a standalone daemon to access a custom device (/dev/mydev0). Looking at AOSP source, I figured I needed setup policies in following files to make it work:
new file device.te containing:
type mydev_device, dev_type;
new file mydevsrvc.te containing
# service flash_recovery in init.rc
type mydevsrvc_type, domain;
type mydevsrvc_type_exec, exec_type, file_type;
init_daemon_domain(mydevsrvc_type)
allow mydevsrvc_type mydev_device:chr_file rw_file_perms;
edited file_contexts to add:
/dev/mydev[0-9]* u:object_r:mydev_device:s0
edited service_contexts to add:
mydevsrvc u:object_r:mydevsrvc_type:s0
And started the daemon by editing init.flo.rc to include these lines:
service mydevsrvc /system/bin/mydevsrvc
class main
user system
group system
seclabel u:r:mydevsrvc_type:s0
oneshot
Now, I need to access the device in android apps, so I must change the daemon into an android system service.
I can startup the service (thread) using BOOT_COMPLETED intent as explained in a previous question
I am not able to figure out how to setup SELinux policies so that this java service is also able to access the dev file.
[Update] I have continued using privileged daemon for this purpose. My java service connects to daemon through sockets. I don't have a better solution.
I finally figured out the answer. Posting it here, because there sure will be SEPolicy noobs like me looking for similar answers.
For this work, I needed to be able to access my device file from my java app that implements my service.
I needed to add following rule in my sepolicy directory, in a new file:
allow system_app mydev_device:chr_file rw_file_perms;
Also, needed to make my service app run in system_app domain. For this, I need to:
Install in priv_app during Android build.
Sign it with platform key
Declare shared user id in manifest: android.uid.system. I found that without this, app runs in platform-app domain and wasn't able to access my device file even with corresponding change in SEPolicy rule. Not sure why though, I didn't bother to debug.
It might also be possible to run my Service app in mydevsrvc_type domain. I didn't find out how to do that, or whether that will work.
Here is a brief summary of the steps needed to implement SELinux on your Android device:
Add SELinux support in the kernel and configuration.
Grant each service (process or daemon) started from init its own domain.
Identify these services by:
Reviewing the init..rc file and finding all services.
Examining warnings of the form init: Warning! Service name needs a SELinux domain defined; please fix! in dmesg output.
Checking ps -Z | grep init output to see which services are running in the init domain.
Label all new processes, drivers, sockets, etc. All objects need to be labeled properly to ensure they interact properly with the policies you apply. See the labels used in AOSP for examples to follow in label name creation.
Institute security policies that fully cover all labels and restrict permissions to their absolute minimum.
Ideally, OEMs start with the policies in the AOSP and then build upon them for their own customizations.
for more https://source.android.com/security/selinux/implement.html
In response of your question to start service from init rc
you can just write one rc file like below. Where it will start your service on receiving of boot_completed
on property:sys.boot_completed=1
start mydevsrvc
for reference http://androidxref.com/9.0.0_r3/xref/device/generic/qemu/init.ranchu.rc#60
Possibly add a line in your ueventd.rc file or project specific to give the permission
Related
I know from https://developer.android.com/guide/topics/connectivity/telecom/selfManaged, that you can set the default dialer by having the necessary items in your manifest and permissions listed. One of those being the Dial intent.
What i'm trying to do is build a library that does all of these content provider calls and provide a nice reactive way of doing things to my application. While building the library I would like to add some integration tests around these device calls.
There's the GrantPermissionsRule that helps with setting permissions already defined in your manifest but how does one deal with becoming the default dialer or SMS application? I'd accept even an adb command that you could run using a Runtime execute command.
I also tried testing on an emulator and I noticed that you can give your app WRITE_SECURE_SETTINGS but not MANAGE_USERS which is the other necessary permission you need if you were to use reflection to access the https://android.googlesource.com/platform/frameworks/base/+/master/telecomm/java/android/telecom/DefaultDialerManager.java
Any help is much appreciated!
you can try adb command:
adb shell settings put secure dialer_default_application com.google.android.dialer
replacing com.google.android.dialer with your package.
First of all, please note that this question is not same as all the "android foreground app" questions I found on SO, please read on :-)
I'm trying to write an android app for my own use, using golang, without using android-sdk or ndk (this is the KEY point). It is pretty simple, just use golang to write a http service, compile it for arm CPU and voila my app is running and can be access by simply visit http://localhost.
For the purpose of my app, I need to know the currently running foreground application, to define it precisely:
Foreground application is the application that occupies the screen, or has an "activity" what-so-ever (forgive me I'm not an android developer).
Anything that that is depended by the foreground application (e.g. services) is NOT what I am interested in.
If the phone is LOCKED/screen turned off, I want the solution to tell me there is NO foreground app.
And since I do not use anything android, just treat the phone as a LINUX machine, I want the solution to use native LINUX ways, e.g. by inspect /proc, or by calling any installed android command line tool (including sending messages via these command line tools), but NOT using any SDK/NDK way so that I have to use java or incorporate these thing into my app.
Starting from Android SDK 26 (if I remember well) Apps are executed on -one-User-per-App, so (i.e.) WhatsApp is running on UID=30 and Telegram on UID=76, so executing a ROOT command of "ps -A -o PID,USER,NAME" you can parse output and then Kill all Processes that you don't want to be executed.
36119 u30_a149 <WhatsApp_packagename>
36203 u76_a211 <Telegram_packagename>
37399 root [kworker/1:2H]
37423 u0_a329 su
38069 root sh
Without Root Permissions nothing of what you're trying to achieve is possible simply because is not possibile to denied an application to be executed or to kill it without Superuser privilege.
I want to excute an executable on boot On a target board with Android 5.1 so I add this in init.rc:
on boot
start myservice
service myservice /system/bin/myservice
#class main
user root
group root
#oneshot
I did the unpack and repack job.
When changes are made, however, the screen keeps printing:
init warning: Service myservice needs a SELinux domain defined. Please fix.
type=1400 ... avc:denied ... scontext ... tcontext ... #some annoying warning messages like this
SELinux seems a huge project for me. I just want to avoid that. I tried two approaches:
1. setenv kernelargs 'console=ttyS0,115200n8 rootdelay=1 selinux=0' and saveenv
2. set enforce 0
For method 1, printenv gives the result:
kernelargs=console=ttyS0,115200n8 rootdelay=1 selinux=0
So you see, changes have been made. But the warning messages keeps printing after rebooting.
For method 2, it says:
Could not set enforce status. Permission denied.
So now I'm trapped in the dilema have no idea where to go. My questions:
Anyone knows how to disable or set permissive mode in android?
Which files should I modify if I want to define domain for the new service?
Besides, ls -Z /system/bin/myservice gives this:
u:object_r:system_file:s0
you need su to set permissive mode. Or you need source code to disable SELinux, such as disable SELinux in kernel config, or disable SELinux in BOARD_KERNEL_CMDLINE in device/vendor_name/product_name/BoardConfig.mk.
if you have the source code, you can define the new domain as you wish.
Please refer to the Android official documents: https://source.android.com/security/selinux/device-policy
section: Label new services and address denials
You have to add the seclabel attribute to the service in your init.rc file, but I don't know if your context will work. I just implemented it myself with the init_exec context:
$ grep yourservice system/sepolicy/file_contexts
/system/bin/vpd u:object_r:init_exec:s0
$ ls -Z path/to/system/bin/yourservice
u:object_r:init_exec:s0 path/to/system/bin/yourservice
$ grep yourservice device/brand/product/init.rc -A 5
service yourservice /system/bin/yourservice
seclabel u:r:init:s0
user root
group root
oneshot
Disabling SELinux on Android isn't hard and there are many threads treating the question. Just add either one of the following to your kernel command line parameters (i.e bootargs in U-Boot):
androidboot.selinux=permissive
androidboot.selinux=disabled
Run into a very similar problem myself, and here's what I've found:
When you run ls -Z /system/bin/myservice and get this:
u:object_r:system_file:s0
it means that your file is in the system_file domain. Now that's not good, as system files are not supposed to be executed, or at last not during init (you may still be able to execute it later from terminal the usual way).
In my case I was lucky, 'cause I was replacing an existing system service with a customised one that I've compiled from source. This means I was able to check the security context of the original file I was replacing and that was from ls -Z /system/bin/myservice.bak :
u:object_r:myservice_exec:s0
So I updated my new file to the same using chcon u:object_r:myservice_exec:s0 /system/bin/myservice
After that it was working fine.
If you want to create a brand new service you may need to use a domain that exists in your sepolicies already, as simply setting it to myservice_exec, won't help, as that would be a non-existing domain in your case.
If I were in your shoes and wanted to avoid defining custom policy I might try to find a service with similar security, check the domain on that and try to set the same to my service. init_exec may be a good candidate, but your mileage may vary...
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
Hi I'm a newbie for Android... Please throw some light on the following issue..
I have a file created by a linux application (written in C) with S_IRWXU|S_IRWXG permission and the file belongs to root user and root group.
Now I'd like to read/write to this file as an Android application as a different user (say app_41). It is not possible for the android application because it has no permission for the file.
What is the best way to implement this (without allowing "others" permission to the file/folder)?
The reason is that I have a daemon written in C that creates and manages named pipes for other process use. I'm trying to write to the named pipe from Android application (using native code) and I don't have the right permission to do it.
I won't be surprised, if someone says... "Hey it is very simple.. do this..."
Thanks for your help!!
I figured out a solution and it works... Please let me know if anyone has any better solution..
For an android application to share a file owened by a root process, we need to do the following
Make the Android application to belong to "system" user using
android:sharedUserId="android.uid.system"
Let the other platform process (owning the file) remain as root, but add it to the group "system".
Now the question is how do I add a process to the group "system".. One quick thing that comes to our mind is to add the process to init.rc and use the "group" keyword and start it. But Android doesn't allow it to happen.
To add the process to group "system" the process has to request the groupid from inside the process. That is, use the setgid(1000) system call from inside the process to add it to the group "system"..
And it works great!