At first, I am not liable for any harm or damage that may happen to your device!
If you have su and didn't trigger knox, I CANNOT guarantee that running this script won't cause 0x1!
Requirements:
1) P905/viennalte/Qualcomm based model ONLY (won't work on Exynos devices. MIGHT work on other Qualcomm LTE deices from Note Pro and Tab Pro series or even S5 / Note 3 etc - feel free to repost but give credits AS THIS METHOD SEEMS TO BE COMPLETELY NEW! ) running 4.4.2 stock;
2) root access with SuperSU (using cf-root - credits to chainfire);
3) busybox installed (I do recommend this paid installer: https://play.google.com/store/apps/details?id=stericson.busybox.donate , MOST PROBABLY free version will be more than enough, too, but I haven't tested it as I have license...)
4) Android Terminal Emulator installed ( free at: https://play.google.com/store/apps/details?id=jackpal.androidterm )
Installation:
1) download file permissive_via_kmem.sh using below link and put it in the root of internal memory (so it will be placed in: /sdcard/permissive_via_kmem.sh)
2) run Android Terminal Emulator
3) at command line, type:
Code:
su -c /sdcard/permissive_via_kmem.sh
(give it an access if requested)
4) voila.
Alternative: if u have init.d support just put the file in /system/etc/init.d to make permissive on every boot
Additional info for advanced users:
1) samsung decided to compile kernels for newer 4.4.2 roms with a flag (a kernel variable) forcing selinux enforcing mode
2) as kernel itself cannot be modified after compiled, it was impossible to set permissive mode using shell or even by repacking kernel's ramdisk, at least on Qualcomm LTE devices
3) custom kernel can do the job, but samsung's sources are broken, at least for P905, and it refuses to boot at all...
4) however, there is a workaround...
5) we cannot change kernel binary to run with different flag out of the box BUT we can obtain it's placement (address) directly in kernel memory space on running kernel and write different value DIRECTLY into the memory, hacking the kernel to make it think that the flag was different
6) for this purpose i believe we have to disable restrictions to access kernel pointers (done via sysctl)...
7) ...then read the output of /proc/kallsyms which will provide a list of all kernel variables along with their addresses in kernel memory space...
8) ...filter out a boolean variable selinux_enforcing which is responsible for all the troubles...
9) ...and write raw 00 byte into the address where the variable value is stored, via /dev/kmem.
Download:
http://www12.zippyshare.com/v/89625246/file.html
Noob question
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
cavkic said:
Could you explain to a newb what this does?
I've read this article on it and still can't fathom what benefits I'd have from changing it to permissive: http://www.androidpolice.com/2013/10/31/kitkat-feature-spotlight-selinux-defaults-to-enforcing-rather-than-permissive-other-new-security-features/
And thank you.
Click to expand...
Click to collapse
Check this
Well, if i'd try to express it in a simple way, from the user's point of view permissive mode is equal to selinux turned off at all, except it is logging (and only logging...) all the warnings caused by security violations, which would result in an error in enforcing mode. Permissive mode let you avoid strict security policies defined by manufacturer (and NSA - yeah, the real spies - which is maintaining general selinux rules), but also gives the possibility of establishing possible issues which may appear after switching to "really secure" enforcing mode.
And if you are asking about the exact, disturbing (ofc if security is not your main priority...) effects of enforcing mode that may affect end-users, we may start from: troubles with write-access to some (mostly external, but i have personally fought with with an issue of non-writeable internal sdcard, too) medias (well, to be honest, I do hope that my discover will help in building 100% working custom recovery...), troubles with non-working system mods resulting from bad selinux file labels, troubles with wiping partitions (ie. wiping cache or even swapping modded system lib sometimes has to be followed by triggering restorecon command on that filesystem (restore selinux context), which is leading to ie. losing root access, which may be fixed by flashing supersu again, etc etc, non working apps (especially related to modifying sensitive system parameters or resources), unchangeable system properties, unreachable functionalities, blah blah blah.... This topic had been widely discussed on xda and over the internet.
On the contrary, if you like to use your device as-is and you're not interested in modding/tweaking it, you will probably not need this mod, as you will gain nothing - but lose a little bit of security... For heavy modders, although, it's a must-have.
Btw can anyone confirm if it's working? I assume that I was looking for solution for some time, made some other changes to the environment meanwhile, so I cannot be 100% sure that above script alone is absolutely enough (but in theory it should...), however, even if it is not, it's just a matter of 1-2 days to figure out what additional, previously-well-known steps, such as running "setenforce 0", may be required in addition.
And as a brief summary: YES, my selinux is now really Permissive, both when running getenforce command and in system settings!
Wysłane z mojego SM-P905 przy użyciu Tapatalka
After following all steps getenforce still returns enforcing and in system it also shows enforcing.
If I try running setenforce I get permission denied.
Ok, can you enter:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
into terminal and tell me what's the output and/or the enforcing state??
Wysłane z mojego SM-P905 przy użyciu Tapatalka
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
RaSand said:
As requested
Output:
/dev/kmem cannot open for write: permission denied
getenforce still returns Enforcing
[email protected]:/ $ cd /dev
[email protected]:/dev $ ls *mem*
ashmem
kmem: Permission denied
mem: Permission denied
ramdump_audio-ocmem
ramdump_smem
smem_log
1|[email protected]:/dev $
Same result in # mode
Click to expand...
Click to collapse
I assume that you have ran the command as root (ie didnt forget about 'su' before the main command)...? Your logs show non-root mode, but ur saying about '#' mode at the end, guess you mean su... Assume that all we do here requires root shell first to be opened, and the output even if similiar, may vary in details between non-root and root mode, so don't forget to get privileges before running anything below...
If so, I guess default policy prevents writing to /dev/kmem in enforcing mode by setting its selinux context to a special one, dedicated only for /dev/kmem and /dev/mem.The working solution is to repack kernel (not same, but, indeed, a lot easier, than recompile - changes won't affect the kernel binary code, but it's ramdisk part, only) with modified policy defaults, which will treat /dev/kmem as a genuine device, not a "sensitive" one. I can provide the one repacked for my own purposes, however, befoure such an intrusion we may want to try other solutions I can think of (again, cannot test it as I ve added many different mods in many different places, I would need to go back to stock to test it, but I need my device 100% steady and configured for my job this week. Hope you'll help me in solving this out, it shouldnt take long...).
Notice: Again, ALL BELOW COMMANDS SHOULD BE RUN IN ROOT MODE. That means you shall enter "su" command alone before trying any of those steps, and the Terminal will switch to a root shell, which is confirmed by switching the last sign in the prompt from '$' to '#'.
Notice 2: if it is written - after some steps - to try switching to permissive mode again, it should be done by running the command from MY PREVIOUS POST only, as it is equal to longer version from the script, just closed within shorter one-liner command... the command should change the mode to permissive itself and no further steps are needed.
1) run following:
Code:
ls -lZ /dev/kmem >/sdcard/info.txt
and paste the exact output (which has been saved at /sdcard/info.txt) here so I can gather further info about issue. Dont make a test of the main script here as nothing has been changed. After that...
2) we can try to set different context (a default one for dev files) manually. Again, it might be impossible as of selinux policy, but worth trying. Enter as root:
Code:
busybox mount -o rw,remount /
chcon u:object_r:device:s0 /dev/kmem
if error, paste it here. If no error, test if permissive mode script is working.
3) we can try to modify selinux policy in temporary ramdisk file to prevent giving /dev/kmem a special context and then restore context of whole /dev to it's "defaults", however, those "defaults" would be our modified ones. Possible issues: not sure if the restoring default context will make use of modified policy or would it use only the policy loaded on-boot (and as the ramdisk is temporary, policy modifications will disappear too within reboot). After getting root, enter:
Code:
busybox mount -o rw,remount /
sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
setprop selinux.reload_policy 1
restorecon -R /dev >/dev/null 2>&1
after that - if no errors - check if the switching works.
4) if none of the above is working, guess we'll need to repack stock kernel with a ramdisk content modified in the same way as in step 3. When embedded in kernel, the changes to the policy rules will be seen every boot and they will affect /dev/kmem in a persistent manner. This will let you write to it for sure. I will provide a ready repacked boot.img, so we can avoid repacking at all. This however is not a very satisfying solution, as my goal was not only to achieve permissive mode, but to achieve it without any changes (even if they are much less disturbing than recompiling kernel from source) to boot partition. But hey, first check out on-the-fly solutions above, as they are much less intrusive to a device, coz won't require reflashing kernel/boot partition.
EDIT: remount command added to step 2, repeat if you had error with changing the context.
Thanks for your effort.
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
RaSand said:
[email protected]:/ $ su
[email protected]:/ # ls -lZ /dev/kmem >/sdcard/info.txt
/dev/kmem: Permission denied
1|[email protected]:/ #
info.txt is empty
chcon: Could not label /dev/kmem with ubject_r:device:s0: Permission denied
2|[email protected]:/ #
waiting for code for 3)
same result in step 2 with added remount
---------- Post added at 04:55 PM ---------- Previous post was at 04:30 PM ----------
It swallowed all commands in 3) BUT re running the script didn't change anything. After please wait.... done it still says selinux is set to Enforcing. Sorry.
getenforce returns enforcing
setenforce to 0 or Permissive doesn't change a bit.
seems it has to be done the hard way
better luck next time
Click to expand...
Click to collapse
Your errors are quite strange, as it seems that you don't even have permissions to check the simple content of a directory...
Try to run commands from step 1 - 3 again, but with slight modifications (below), so theyll run in separate, undoubtly-rooted shell... Test also with modded command (you can try it alone before in the very beginning...)
Also: please run 2 and 3 in reversed order, ie. first step 3 and if not working, without rebooting, run step 2...
Btw are you using SuperSu 1.99? If no - after trying all below options, upgrade SuperSu from the Play Store, run it to update the binaries, reboot. check commands again. If still the same, install update to /system using option from its menu (it will do some cleanup and ask to reboot, after that you have to run option again, this time it will perform installation, after which you have to reboot again - after boot run SuperSu and check if the option is greyed out, if yes, everything went fine) and check all steps once again...
Here we go.
Main command:
Code:
su -c printf '\x00' | dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
Step 1 v2:
Code:
su -c ls -lZ /dev | grep kmem >/sdcard/info.txt
Step 2 v2 (formerly step 3 ):
Code:
su -c busybox mount -o rw,remount /
su -c sed -i "s:^.*\/dev\/[k]*mem.*$::g" /file_contexts
su -c setprop selinux.reload_policy 1
sleep 3
su -c restorecon -R /dev
Notice: I am not sure if setprop selinux.reload_policy 1 is enough to force sammy's android (which is a really giant b***ch to hack when compared to any other android...) to reload the policy, this may really work, but only if the policy is reloaded on-line using new defaults. Later I will look for that information...
Step 3 v2 (formerly step 2 - please run directly after step 2v2, without rebooting...):
Code:
su -c busybox mount -o rw,remount /
su -c chcon u:object_r:device:s0 /dev/kmem
Notice: step 3 - when ran fine - might now print some errors that it cant access some stuff in /dev - this is absolutely ok. But formerly I disabled the output at all (not to confuse you with some strange errors), but it resulted in lack of possibility to find out if the command ran AT ALL or if it escaped because of no permissions on the very beginning.
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
RaSand said:
Before we go on here let's get a few things out of the way.
1) please advise where i should get supersu 1.99 from. I'm on 1.94 and in my country (GE) there is no newer version available in the play store.
2) first thing I usually do when I start the terminal is type "su"
3) I'm an old man. So please be patient
that said let's give it another try
---------- Post added at 06:42 PM ---------- Previous post was at 06:11 PM ----------
This is starting to test my temper. I guess I will put the steps into files and run them with gscript. Hang on. Might take some time
---------- Post added at 07:30 PM ---------- Previous post was at 06:42 PM ----------
Guess I had it for today. No changes whatsoever.
Here is what I did
installed supersu to /system. Option is greyed out now
made a new script for every box of code. Main and step 1 to 3
Made copies and added some echo lines so I could see if scripts work and/or finish correctly
executed scripts with gscript in the given order
No echo in step 1 to 3
ran original code
same result.
don't know what else to try.
sorry
Click to expand...
Click to collapse
Stay cool. I am a (quite) young man, but I have patience, too ;]
No output when running *something* as su = faulty su installation (maybe)...
Please download SuperSu 1.99 (flashable cwm version) from here: http://forum.xda-developers.com/showthread.php?t=1538053 and put it somewhere on internal sdcard
Download my "almost-working" TWRP recovery image: http://www53.zippyshare.com/v/30690424/file.html
Put it in internal mem so its path will be /sdcard/twrp2.img
Run terminal emulator (CAREFULLY WITH THE PARTITION NUMBERS!)
Code:
su
dd if=/dev/block/mmcblk0p15 of=/sdcard/recovery.backup.img
sleep 1
dd if=/sdcard/twrp2.img of=/dev/block/mmcblk0p15
sleep 1
sync
reboot recovery
In recovery, flash downloaded supersu zip. Reboot.***
Try commands again.
Maybe your busybox is bad? Can you tell me the output of command busybox written alone without further params?
***(btw the recovery may be useful, but it is not-fully-working, however, it is working AT ALL... be aware of issues:
- it cannot write backups to exfat external cards, vfat/fat32 only
- it may mess the selinux context, especially for cache partition after wipe. solution: from twrp run advanced -> console (or terminal? dont remember) and run
restorecon -R /cache
- if u ever have a bootloop after flashing a (even reliable...) zip, you should get back to twrp, click mount menu, mount everything, switch to advanced -> console and run:
restorecon -R /system
restorecon -R /data
restorecon -R /cache
selinux contex will be fixed BUT it will mess context for su binary, so in the end flash supersu again and reboot, everything will be ok.
If you want to revert, just do:
dd if=/sdcard/recovery.backup.img of=/dev/block/mmcblk0p15
).
And last but not least, kernel which I have promised (BUT if you use it, I will lose my only tester heheee):
http://www46.zippyshare.com/v/63874309/file.html
Please be aware that there are some other tweaks included (like unsecure adb, faster filesystem mount options but with higher risk of data loss, etc).
Put b4.img to /sdcard/b4.img
Run:
Code:
su
dd if=/dev/block/mmcblk0p14 of=/sdcard/boot.backup.img
sleep 1
dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
sleep 1
sync
reboot
You can revert to stock by dd if=/sdcard/boot.backup.img of=/dev/block/mmcblk0p14 (or by flashing full stock by odin). Would be glad if you can confirm that mode is permissive using this repacked kernel (HOPE IT WILL!!!!) and after some time you'll flash the backup back, to help me solving the case, as i suppose that there IS possibility of permissive without the kernel flash and I need a tester ;} It would be reeeeeeaaaaaaaally nice...
BE AWARE THAT:
- it's for note pro 12.2 LTE ONLY!!!! also called viennalte or SM-P905... It WON'T work on other devices and it may damage them (for example, coz of different mmcblk numbers...)
- messing the mmcblk0pxx number may cause an unrecoverable harm to your device (especially if you overwrite bootloader partitions or your efs partitions where unique imei is stored), it's 14 for kernel (boot) and 15 for recovery
- your knox WILL be tripped (if it hasnt been tripped yet... but it's not very probable )
- on the very first boot screen, a warning messages may appear in the left-top corner, about some warranty stuff. Ignore them, they'll disappear after reverting boot/recovery to stock.
Regards.
Just done flashing twrp and supersu(now 1.99)
i will not give up that easy, don't worry.
Just to be on the safe side i downloaded b4. Maybe you should remove it for the moment.
Looks like fun being the most important part of the team.lol.
btw. Knox was tripped about 2 hours after i got the device
busybox is v1.22.1 (2014-01-25 17:27:18)
---------- Post added at 10:05 PM ---------- Previous post was at 09:15 PM ----------
This it what happened after the last command in step 2 was executed
Could not label /dev/cpuctl with ubject_r:cpuctl_device:s0: Operation not supported on transport endpoint
Could not access /dev/kmem: Operation not supported on transport endpoint
Could not access /dev/mem: Operation not supported on transport endpoint
Could not label /dev/pts with ubject_r:device:s0: Permission [email protected]:/ #
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
RaSand said:
After this I will reboot
127|[email protected]:/ # dd if=/sdcard/b4.img of=/dev/block/mmcblk0p14
18468+0 records in
18468+0 records out
9455616 bytes transferred in 2.044 secs (4626035 bytes/sec)
[email protected]:/ # sync
[email protected]:/ #
---------- Post added at 02:08 PM ---------- Previous post was at 02:00 PM ----------
One would expect to have a new kernel after the above, but guess what
[email protected]:/ $ su
[email protected]:/ # getenforce
Enforcing
[email protected]:/ # setenforce Permissive
127|[email protected]:/ # getenforce
Enforcing
[email protected]:/ #
and the kernel set the warranty bit for kernel change, but it didn't make it to block 14 as I still have the stock kernel
Click to expand...
Click to collapse
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..
The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).
To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).
If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).
After that, there should be no further doubts that you have unlocked /dev/kmem for writing!
On this step you still need to run the command from my post on top of the topic, this one:
Code:
su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc
setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...
Then check enforcing status. Now it really should work.
If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
RaSand said:
Sorry for letting you wait that long. I was out in woods all day and did not even take the Tablett with me. Besides that there was no service whatsoever.
After running your script, wich for whatever reason I didn't do yesterday, I do have permissive selinux. As you suggested I play with it a couple of hours till bedtime and re flash stock after that to do more testing if you come up with new ideas and need a tester.
bee back in the morning, or maybe before I lay my tired head to rest.
congrats for the job you did till now.
edit:
Just checked file_contexts and the lines for kmem and mem are commented out. So for the moment I'm definitely on your kernel. Thanks again
Click to expand...
Click to collapse
good, thank you for testing and hope enforcing linux won't bother you again ;] you're probably a second man on the planet who is running your machine in permissive
and don't worry about anything, it's not a race or something. i am most thankful that you found a time to run all the suggested stuff, and for patience.
please however note that leaving open /dev/kmem shall be considered as a serious security hole! it allows root app to write ANYTHING to ANY part of memory. Well, that's was an obligatory warning, however, I was never scared too much with security issues and until now nothing bad happened so..
Let's summarize:
- now I am sure that my script is working BUT only after giving it possibility of writing to memory via /dev/kmem
- writing to /dev/kmem is possible only after changing the security policy, which lies in kernel's ramdisk
- the final appropach shall also CLOSE the access to /dev/kmem just after changing the selinux mode for security reason
- the aim is to make a complete modification which will make use of only one area of the device ie. system OR kernel, not both, as it is too intrusive:
- find a way to reload policy when device is on-line, so writing to /dev/kmem will be possible (it's a preferred method, no need to flash anything and no need to watch ugly warranty message - but I doubt if it's possible - it would be an equally dangerous security issue, there is no practical difference between letting write to memory and between letting to open the possibility of write to memory and then letting write to memory ... or
- implement the memory write technique straight in the kernel's ramdisk.
I will be back with new stuff, soon.
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
RaSand said:
Before you surprise us with new stuff, could please change the command to revert to stock kernel in post #12. Somebody might get into trouble by just running the command and put the kernel in the wrong block. And while you are at it. It should be if=/ not if-/ in the code field.
Click to expand...
Click to collapse
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
esgie said:
Thank you, changes made, no one should flash the wrong block device (although flashing boot to recovery - which is possible, as the boot partition size is 2meg smaller than recovery - shall result in nothing but... booting the device when entering recovery mode ;] - that's just fyi, of course, mistakes corrected...)
Click to expand...
Click to collapse
Esgie, is there any further developments with this script? I've given it a shot and even after running the script, SELinux remains in Enforcing mode.
I see that you have the modified kernel for SELinux in permissive mode, but I really like the approach of having this script rather than using a modified kernel, so I'm wondering if in your process of getting the kernel to work, there might be something you've discovered that would make this script work as well.
Thanks.
As the title suggests, I'm attempting to compile a (Lollipop) Nexus 5 kernel with SELinux in permissive mode by default. For reference, I am using the msm kernel source tree at commit 8a80a0e.
I have managed to accomplish this by modifying msm/security/selinux/selinuxfs.c and inserting new_value = 0; into sel_write_enforce to prevent the mode being changed:
Code:
length = -EINVAL;
if (sscanf(page, "%d", &new_value) != 1)
goto out;
new_value = 0; /* inserted this line */
if (new_value != selinux_enforcing) {
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
"enforcing=%d old_enforcing=%d auid=%u ses=%u",
This method, however, doesn't seem particularly good, as it relies on the intricacies of the specific implementation of SELinux used in this kernel, and prevents the mode being changed later.
This post suggests changing the CONFIG_ALWAYS_ENFORCE flag for a Samsung device, however the Nexus 5 kernel does not appear to have such an option. Setting the default state of SELinux using various menuconfig options and kernel command line parameters does not appear to have any effect, and disabling it entirely causes the device to crash after boot, before any logcat output is produced.
I have noticed than when started with a kernel with SELinux enabled, one of the first messages from logcat is from auditd, of the form enforcing=1 old_enforcing=0 auid=... ses=..., indicating that something is setting the SELinux mode to enforcing almost immediately after boot.
Thus, I am wondering if anyone knows where this command to set SELinux to enforcing comes from, how to disable it, or another way to compile a kernel with SELinux set to permissive?
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
Doesn't work. The system boots up in permissive mode, but immediately switches to enforcing, as it usually does. The first few lines of logcat:
Code:
--------- beginning of main
I/installd( 0): installd firing up
W/auditd ( 169): type=2000 audit(0.0:1): initialized
I/auditd ( 169): type=1403 audit(0.0:2): policy loaded auid=4294967295 ses=4294967295
W/auditd ( 169): type=1404 audit(0.0:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.
Gene Poole said:
Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.
Click to expand...
Click to collapse
I wasn't aware there was a difference. I compiled the kernel from source, enabling the relevant config options, then got boot.img from the Nexus 5 factory image, and extracted and replaced the kernel and boot parameters as suggested by this document.
The boot.img built as part of the AOSP build (with USERDEBUG flag) is not locked down the way the factory boot image is. There may be something built-in to the init process to ensure selinux is available in the kernel and cannot be disabled.
I wish I knew more about this. My original goal was to implement the things I needed in the AOSP build and set up selinux permissions to allow it, but I gave up and ended up just removing selinux from the kernel altogether.
Hmm... I'll take a look in the initrd of the Android boot images to see if there's anything in there that might be setting the SELinux mode.
Update: Bah. It seems the AOSP source of init can be configured to accept a ro.boot.selinux parameter, but I see no indication that the code is present in the stock init binary. The code also explains why the phone immediately reboots into recovery when SELinux support is disabled in the kernel.
Update 2: After attempting to download 18GB of AOSP source code, I think my dodgy way of disabling SELinux is really the best method.
Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
bootloop ¯\_(ツ)_/¯
Just disable it in the config?
Why do you need it if you don't use it?
Jo_Jo_2000 said:
Just disable it in the config?
Why do you need it if you don't use it?
Click to expand...
Click to collapse
I prefer CONFIG_ALWAYS_ENFORCE = false instead of new_value = 0