I am modifying SELinux policies for a hardware device running Android 9.
Currently my process is like this:
Run the device as userdebug but with SELinux set to enforcing
Make changes to .te files and/or file_contexts
Build the policies using mmm system/sepolicy
Push the policies on the device using the following script:
adb root
adb wait-for-device
adb remount
adb wait-for-device
adb push out/target/product/<PRODUCT_NAME>/vendor/etc/selinux /vendor/etc/
adb push out/target/product/<PRODUCT_NAME>/system/etc/selinux /system/etc/
adb shell sync; sync; sync;
adb reboot
Test and go back to step 1 if needed.
This process seems to work fine when modifications involve .te files. But when I modify the file_contexts, this doesn't work, and labels I changed are not applied on the device.
For now, I have to do a full make and flash when I modify file_contexts, which is very time consuming...
So is there a way to apply file_contexts changes without a full make/flash ?
Check if there is product/etc/selinux or odm/etc/selinux in the ${ANDROID_PRODUCT_OUT}.
If they exist, you have to push them into the device too.
The file_contexts is only applied if the file or directory is created via init.rc or after running the restorecon command.
If the file or directory is created by adb shell or any other process runtime, the selinux context will inherit its parent.
Related
I have tried to follow the instructions from Movesense on how to do Whiteboard communication using ADB. This does not work as expected.
On a sidenote - I'm just trying to set up a handful of sensors to start some heart rate and movement measurement and store data to the logbook. After 30-40 minutes, I want to stop measurements and fetch the data from each device. My first dream was that I could do this using Whiteboard over BLE (from Matlab, Python, LabVIEW, ...) without having to use ADB or similar solutions. But I guess this was a bit too optimistic.
Setup
Installed the adb tools: OK
Enabled USB debugging on an Android phone: OK
Tested that adb can install apps and handle the phone: OK
Installed sampleapp-debug-1.5.1.apk:
Tried to install using adb: OK
Tried to install by copying the file to the phone and installing it there: OK
I got a message saying that the sample app was not compiled for the current version of Android (I'm using a Samsung S10e running One UI version 4.0 and Android version 12, security fix level 01.02.2022).
Im working on an Intel Mac running Big Sur 11.6.5 with plenty of resources.
What I've tried so far
First of all, I start the app and connect to the MOVESENSE device.
When trying the example commands from Movesense, I get:
Switch on LED:
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":true}'''
Broadcasting: Intent { act=android.intent.action.MOVESENSE flg=0x400000 (has extras) }
Broadcast completed: result=0
Get Info
Get Info does only work if I place curly braces between the quotas. See results below for both variants.
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type get --es path Info --es value ''''''
Exception occurred while executing 'broadcast':
java.lang.IllegalArgumentException: Argument expected after "value"
at com.android.modules.utils.BasicShellCommandHandler.getNextArgRequired(BasicShellCommandHandler.java:295)
at android.content.Intent.parseCommandArgs(Intent.java:8329)
at com.android.server.am.ActivityManagerShellCommand.makeIntent(ActivityManagerShellCommand.java:367)
at com.android.server.am.ActivityManagerShellCommand.runSendBroadcast(ActivityManagerShellCommand.java:788)
at com.android.server.am.ActivityManagerShellCommand.onCommand(ActivityManagerShellCommand.java:214)
at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
at android.os.ShellCommand.exec(ShellCommand.java:38)
at com.android.server.am.ActivityManagerService.onShellCommand(ActivityManagerService.java:10429)
at android.os.Binder.shellCommand(Binder.java:986)
at android.os.Binder.onTransact(Binder.java:860)
at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:6049)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3034)
at android.os.Binder.execTransactInternal(Binder.java:1220)
at android.os.Binder.execTransact(Binder.java:1179)
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type get --es path Info --es value '''{}'''
Broadcasting: Intent { act=android.intent.action.MOVESENSE flg=0x400000 (has extras) }
Broadcast completed: result=0
The suspects
Is my problems due to an old version of the Android app? I could not find anything newer than 1.5.1.
I tried to poke around a bit in the phone using adb shell dumpsys activity services | grep android.intent.action, and got a load of results, I then started to look for MOVESENSE as well using adb shell dumpsys activity services | grep MOVESENSE, and got no hits. I'm on thin ice here, but could it be that there should be an android.intent.action.MOVESENSE in there someplace?
After a lot of trial and error, I have finally found a solution.
The solution
I found aBitbucket directory with a lot of precompiled Android apps.
The file Showcaseapp-debug_adb-bridge-build.apk is the one you want. Here is what you do:
Download Showcaseapp-debug_adb-bridge-build.apk, and place it in your directory of choice.
On your Android device, uninstall the Showcase app if you have installed it already.
Install the app using ADB on your computer: adb install Showcaseapp-debug_adb-bridge-build.apk.
Start the app on your Android device and connect to the Movesense device.
Try a command like:
Switch LED on: adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":true}'''
Switch LED off: adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":false}'''
A final note
In a perfect world, Movesense would make wbcmd capable of using theBLE device built into most/all PCs, be it Windows, Linux, or Mac. Or even perfecter (is that a word?), make a variant that used TCP/IP instead of standard in/out.
I am running on Pop!_OS so for most things this is likely an aquivalent of Ubuntu.
KeepassXC is installed and the SSH-Agent is enabled.
There is a keyphrase configured with a key and it works just like a charm when I start keepassxc from the terminal keepassxc log in and then I can see that ssh-add -l lists an additional key. It also vanishes once I close KeePassXC. Perfect!
Now I start keypassXC from the gnome shell, hit the super key, search for keepassXC and log into its vault. Looking at ssh-add -l in the terminal: Nothing. No keys added. 😔
Now I took a look at /usr/share/applications/org.keepassxc.KeePassXC.desktop and changed Terminal=false to true. No, sadly not that easy.
My guess that it has something to do how the gnome shell starts KeePassXC, but can't say for sure what the problem is. Anyone got a clue what that could be or how to take a shot at the problem?
I got the KeepassXC ssh agent working on Ubuntu 16.04.6 with Unity as the window manager.
The issue is that if the SSH_AUTH_SOCK environmental variable is not set before the window manager starts it is not available for programs started in the window manager.
Some distributions have a system for starting programs such as the ssh-agent before the window manager. On my distro I found that /etc/X11/Xsession.d/90x11-common_ssh-agent was starting ssh-agent. See this comment on a user help issue for KeepassXC for more information.
However I also found that GNOME Keyring was starting an ssh agent of its own. I had to disable this in the startup applications. I also checked that no shells startup scripts (ie. .bashrc .bash_profile .profile .config/fish/config.fish were trying to start the ssh-agent, as doing so would replace the one started before the window manager.
An interesting side note, the ttys, that you get to with Ctrl+Alt+F1, Ctrl+AltF2, etc., also do not have the SSH_AUTH_SOCK environmental variable set as they start up before the window manager. If you need it here you can add code to find and set the SSH_AUTH_SOCK. For the fish shell I added the following to ~/.config/fish/config.fish:
# Set SSH_AUTH_SOCK if not set.
if test -z "$SSH_AUTH_SOCK";
set -gx SSH_AUTH_SOCK (find /tmp/ -path "/tmp/ssh-*/agent.*" 2>/dev/null)
end
I also found that in the upcoming 2.6.0 release of KeepassXC (targeted for 3. April 2020), there will be an added settings to allow overriding, or settings the value to use for SSH_AUTH_SOCK. However as this changes each time ssh-agent starts you will either need to keep changing it or set-up a link that would point to the current sock.
We are running the latest raspibian on the raspberry pi board and have a kernel driver for a USB peripheral which is added externally (sudo insmod driverx.ko) after boot-up by connecting to the hardware using ssh (its a headless system).
The problem is as follows:
If the device is already connected to the system upon power-up then running sudo insmod driverx.ko leads to the terminal getting stuck (no response, Ctrl+C doesn't work). Running lsmod by starting another ssh session shows that the module is in use even though there is no code running that will use it.
If I plug the USB device after the system boots up then sudo insmod driverx.ko works normally, (the terminal is still active). Running lsmod subsequently shows that that module is loaded but not in use by anyone. I can then run my user code and everything is fine. Upon running my user code lsmod shows the kernel module is in use and the number of users is 1.
In our system the USB device will always be plugged in. The kernel version and the driver version are the same.
I can fill in more details but do not wish to bias or make this query un-readble.
Please advise on what could the problem be.
Thank you for your time and help.
Possibility is that, the device is already attached into some other driver during startup. If it’s the case, the device credential of your specific device has to be removed from the startup driver.
Check the USB device list before to insert your driver.
I am currently working on centos running on intel atom board. I mistakenly renamed lic-2.17.so to _libc-2.17.so
library on my board, when I reboot the board it is giving me below error.
[ OK ] Reached target Initrd Default Target.
systemd-journald[136]: Received SIGTERM
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
Is there any possible way to get back to the original state.
I entered into grub prompt and able to see cat /lib64/_libc-2.17.so. Not Sure,
how to rename this to original name
Thanks in advance.
Can you enter run-level 3 from grub?
if so,
sudo mv /lib64/_libc-2.17.so /lib64/libc-2.17.so
if you can't enter run-level 3, you can try using a live DVD/USB to run the above command, you're just going to have to manually search for the right partition which the incorrectly named file is located.
Otherwise, I'm afraid you're going to need to reinstall the OS.
When I start the `Paste' web server in daemon mode, it seems to kill off it's ability to reload when the timestamp of a source file is updated.
Here is how I start the daemon...
cd ${project} && ../bin/paster serve --reload --daemon development.ini; cd ..;
...which defeats one of the main points of using Paste (for me).
Has anyone come across this or know what I'm doing wrong?
To be complete, the file that I'm changing is a controller file.
The version is `PasteScript 1.7.3'
I believe that the two options are essentially incompatible, since the reloader stops the server with a SIGTERM and the daemon-ized server is impervious to that -- and since daemon is intended for running in a production environment, and reload for a development/debugging environment, I guess that their incompatibility is not seen as a big loss. I imagine a customized reloader, tailored to properly stop and restart the daemonized server, could certainly be developed, but I don't know of any existing one.
I had a similar problem and circumvented the problem. I currently have paster running on a remote host, but I am still developing, so I needed a means to restart paster, but manually by hand was too time consuming, and daemon didnt work. So I always had to keep a shell window open to the server and running paster without --daemon in there. Once I finished my work for that day, and i closed the shell, paster died, which is bad.
I circumvented that by running paster non daemonized in a "screen".
Simply type "screen" in your shell of choice, you will usually depending on your linux be presented with a virtual terminal, that will keep running even when you log out your remote session. Start paster as usually in your new "window" (the screen) with --reload but without daemon, and then detach the window, so you can return to your normal shell (detach = CTRL-A, then press D). You can re-enter that screen by typing "screen -r". If you would like to kill it, reconnect it (screen -r) and inside the screen type CTRL-A, then press K.
Hope that helps.