Android 2.2 sets the default hostname to android_dfhjkahdjksf or something equally useless.
To override this in Cyanogen 6.1 you need to set the net.hostname property with setprop Eg:
# setprop net.hostname mickey
My problem is when I try to set this up at boot, something always overwrites my change with the default. I have tried putting it in my init.rc, /etc/init.d and /data/local/userinit.sh and it is always reset to default by the time the phone has booted.
Does anyone have any more ideas about how to permanently set the hostname? It would be a good option to have in cyanogenmod.
UP. I'm very interesting too.
The root filesystem is stored in the boot.img and is expanded to a ramdisk every time you reboot. For changes to be permenant, you need to extract the boot.img file, extract the kernel and ramdisk sections, modify the ramdisk image with your changes, then recombine the kernel and ramdisk to a new boot.img and reflash it. You'll probably need to do this on a linux machine that understands unix permissions and ramdisk/cpio filesystems as well as having a good knowledge of linux and unix commands. See this thread:
http://forum.xda-developers.com/showthread.php?t=551711
note: your kernel may use a different "--base 0x19200000" option when building the kernel boot image.
Is there not a way to add a correlating line to the build.prop file?
EDIT: This doesn't work - whatever is setting the net.hostname writes out after build.prop is read.
I'm looking...
I did a search in the /system/etc directory for any file doing setprop (I'm using a miui rom) and found the following script. I did the setprop for net.hostname in there and it too is being overwritten.
search command:
grep -H -r setprop /system/etc
/system/etc/init.goldfish.sh
I'm running out of ideas other than using autostart to set it after reboot.
EDIT2: doh. I think I already knew this but it dawned on me that the default net.hostname comes from concatenating the "android_id" (found in the secure database table) to the end of "android_".
So seems more likely to reset it after reboot using a script (gscript to launch it manually or use autostart to launch it automatically at the end of reboot cycle).
Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.
Really interesting, thx !
BlaY0 said:
Property net.hostname originate from services.jar (ConnectivityServices.java):
Code:
// setup our unique device name
String id = Settings.Secure.getString(context.getContentResolver(), Settings.Secure.ANDROID_ID);
if (id != null && id.length() > 0) {
String name = new String("android_").concat(id);
SystemProperties.set("net.hostname", name);
}
Maybe CM guys would change this to add another "if /proc/sys/kernel/hostname is different than localhost, use it for net.hostname too" condition.
I'm not using CM so it is up to you guys to make a feature request.
Another approach would be to set service in init.rc that would start your net.hostname changing script on some property being set just after net.hostname is set. You could use also:
Code:
on property:net.hostname=android_blahblah
...but that wouldn't be so handy since you will have to change that line in init.rc every time you make a factory reset.
Click to expand...
Click to collapse
Thanks a lot. I've been looking for this for the past hour or so. Traditional linux methods to set the hostname don't work... I think I'll add an option in cyanogenmod settings for this and submit it to Gerrit. Look for it to show up within the next day or two.
That's great m8! Cheers
Sent from my HTC Legend
underscores in hostnames are bad
The main thing I want to do is get rid of that underscore. Several of the places I hook up with with WiFi attempt to enter the hostname supplied during the DHCP conversation into a DNS. But underscore is illegal for this purpose.
Numbat.
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to Q&A
Has anyone successfully established a bridge mode VPN connection (using TAP) in any version of Jellybean, stock or custom?
It seems that every vpn app in the play store suggests that this can't be done in JB. I'd really like to upgrade to JB, but I really don't feel like reconfiguring my whole VPN setup, just to log on to my home server every once in awhile.
Hoping I'm wrong about this...
ushlambad said:
Has anyone successfully established a bridge mode VPN connection (using TAP) in any version of Jellybean, stock or custom?
It seems that every vpn app in the play store suggests that this can't be done in JB. I'd really like to upgrade to JB, but I really don't feel like reconfiguring my whole VPN setup, just to log on to my home server every once in awhile.
Hoping I'm wrong about this...
Click to expand...
Click to collapse
Yes all you need to do is search Open VPN Tun [short for tunnel and the name OpenVPN gives the setting] in the Android Play Store to find the Open VPN Settings app created by: Friedrich Schäuffelhut
[Found Here: Open VPN Settings]
When you run it it will run some checks and may ask you to download the following to install the ifconfig binary and the Open VPN binaries in to the system [ifconfig is installed as part of busybox so you maybe good may not but app checks and runs well].
Installer Link [which can also be run on it's own and also checks things and will tell you if you are good to go or if it needs to install things for you.
Open VPN Settings Installer
IF UNSURE USE /system/xbin for install location [first question] and accept defaults or the rest.
THIS WILL REQUIRE A ROOTED ANDROID DEVICE [due to it being a tunnel and not a tap interface you need root to set the connection up and make it usable within android the android VPN client itself only accepts TAP style interfaces due to possible security risks "casual" or "non-technical" users may not understand and thus to protect you from yourself it doesn't do TUN interfaces.
You can use either blah.ovpn OR blah.cfg [Windows servers use .ovpn as extension whereas Linux favors .cfg but both are the same text based profile file]. if I remember right just create /sdcard/openvpn/<whatever> [whatever is whatever directory name [if you want one] I use the client name that way all the keys and profiles are organized and not all jumbled in one folder [or if files have same name or different content then you will be forced to do this for something like multiple OpenVPN server profiles]. THE OpenVPN app tells you this if you open it and there is no /sdcard/openvpn folder found it says to create it in the middle of the main window area]
Also, it is easiest to edit your profiles so there is no absolute directory structure pointing to the files [the ca.crt, client.crt and client.key files].
This is very easy just remove all directories so the line ONLY has the filenames [See example profile in code box below].
Here to make this easy here is an example profile file I use [your server and port as well as if you choose to have it persist the IP addresses of clients across multiple connections may be different, up to you].
Code:
.
# Specify that this is a client
client
# Bridge device setting
dev tun
# Host name and port for the server (default port is 1194)
# note: replace with the correct values your server set up
remote some.domain.or.IP.address.here <whatever port you use here>
# Client does not need to bind to a specific local port
nobind
# Keep trying to resolve the host name of OpenVPN server.
## The windows GUI seems to dislike the following rule.
## You may need to comment it out.
## This MAY NOT be a good choice
## for most folks I use a private server
## without many clients so it doesn't
## affect me if they connect a bunch of times but any security systems
## may not like it if you connect too many times to quickly and you don't
## want your own server blocking your IP when you want to connect now do you :)
resolv-retry infinite
# Preserve state across restarts
persist-key
persist-tun
# SSL/TLS parameters - files created previously
ca ca.crt
cert client.crt
key client.key
# Specify same cipher as server
cipher <choose your cipher>
# [same as you set on your server don't make it different]
## Default here is usually BF-CBC if I remember right
# Use compression
## again make sure you enabled compression in the server profile or comment it out here
comp-lzo
# Log verbosity (to help if there are problems)
## I set it a little higher but not totally verbose
## I like a little info when there are problems
## to help fix them, up to you what you choose
## Can be different from server setting
verb 3
Hopefully this helps. I am unsure of your or anyone else who may like this posts technical skills so trying to be thorough. You could also use this profile to work backward filling in the same settings asked for in the server profile.
ONCE YOU GET THE profile on to the SDCARD and connect the first time the app will always bring it up and all you have to do is tap a checkbox to turn on the VPN Settings app and then once more to enable the profile you want [yes even if just one you have to check it, BUT, IF YOU uncheck the OpenVPN enable/disable checkbox at top the next time you enable it it will auto enable last used connection !
IT REALLY IS A VERY EASY TO USE AN NICE APP [AND ONLY ONE TO SUPPORT OPEN VPN TUN [TUNNEL] INTERFACE SETUPS!
The following link gives a brief description about package installation process in android.
java,dzone,com/articles/depth-android-package-manager
I'm curious to know how the UID of an app is determined during its installation based on set the permissions present in its manifest file.
Also there is the platform.xml (in /frameworks/base/data/etc directory for 4.0 ICS Source code)file which contains list of permissions with gid associated with them. The description says
The following tags are associating low-level group IDs with permission names. By specifying such a mapping, you are saying that any application process granted the given permission will also be running with the given group ID attached to its process, so it can perform any filesystem (read, write, execute) operations allowed for that group.
In a similar way there is a list of high level permissions assigned to specific uid's as well.
My question is when an app is installed with permissions X,Y, Z how does its access specified is it from the mapping from this platform.xml
Also everytime the app is run does the mapping take place at every instant (that doesn't seem right from the initial design of android where the app permissions cannot be changed unless there is an update). So if that is the case where does it store saying this app should run with such and such access or such and such uid.
I hope I made my question clear, let me know if you need more information. I'm just trying to learn more on how the internals of the Android OS work.
Thanks
Android's netd daemon, by default, enables something known as "IPv6 privacy extensions" (this means that the IPv6 address, instead of being generated from the device's MAC address, will be randomized — but this is irrelevant for my question).
In a nutshell, my problem is this: how can I hack, or communicate with, the netd daemon to force it to disable this feature?
(Android offers no configuration for this. I bug-reported the issue to Google ad android bug #31102 aka http : / / code.google.com/p/android/issues/detail?id=31102 (sorry I'm not allowed to post links) but they, of course, ignored it. Please note that there are lots of pages dealing with the question of how to enable IPv6 privacy extensions, because old versions of Android did not enable them: my question is how to disable them, permanently.)
What the netd daemon actually does is that when a network interface $IFACE is brought up, it opens the file /proc/sys/net/ipv6/conf/$IFACE/use_tempaddr and writes "2" there (this asks the Linux kernel to enable the feature). Up to Android 4.2, what I did was binary patch netd to replace the string "/proc/sys/net/ipv6/conf/%s/use_tempaddr" by "/dev/null\000" so the daemon would simply write that "2" to /dev/null and nothing would happen. But in Android 4.3 that part of the code has been slightly refactored, see InterfaceController.cpp from the netd source code, around line 134 (https : / / android.googlesource.com/platform/system/netd/+/android-4.3.1_r1/InterfaceController.cpp — again I'm not allowed to put links, what a pain), so a binary patch is not so trivial. (I could probably replace "use_tempaddr" by "hfr_grzcnqqe", but it would cause an error message in the logs and I'd like to avoid that.)
(Changing netd's source would be absolutely trivial. But I want to avoid recompiling it, because I'd probably spend many sleepless nights getting the correct native toolchain and convincing the Android makefiles to recompile just this bit: I don't have the resources to do a full Android build. Maybe I'm being pessimistic.)
In principle, it seems that netd reacts to commands that are sent to it (see https : / / android.googlesource.com/platform/system/netd/+/android-4.3.1_r1/CommandListener.cpp starting from around line 434). What I don't know is how to communicate with it to send it such commands, let alone do it precisely when a new interface is brought up. I know that at the other end of the line there is, for example, android.net.wifi.WifiStateMachine (see https : / / android.googlesource.com/platform/frameworks/base/+/android-4.3.1_r1/wifi/java/android/net/wifi/WifiStateMachine.java around line 2104). I'm a Linux dev, not so familiar with the Android IPC mechanisms or daemons, so I was hoping someone more knowledgeable could think of a way to pass a command at the right time.
PS: I'm aware that there's an app called to.doc.android.ipv6config which claims to solve the problem I'm talking about. But, looking at the code (https : / / gitorious.org/android-ipv6config/android-ipv6config/source/58e2060162485b54d4f8c147a558aeed708fa4b4:src/to/doc/android/ipv6config/LinuxIPCommandHelper.java around line 103), it's obvious that it does so in a completely wrong way, namely by talking to the kernel, bypassing netd's role as the network gatekeeper altogether.
PPS: I'm using CyanogenMod (currently 10.1.3, and this issue is preventing me from upgrading to 10.2), but I don't think this is relevant at all (I must admit I didn't check to see if CyanogenMod patched netd and/or android.net.wifi.WifiStateMachine in any way).
Meta-question: Is this the right place to ask? Apparently I have to ask 10 stupid questions before I'm allowed to post anywhere else.
Did you ever find a permanent solution? I've been tackling the issue on my new Galaxy S6 using the steps as outlined in this link:
https://www.reddit.com/r/Android/comments/2z1gyo/fix_lollipop_wifi_issues_and_coincidentally_the/
On the chance that someone has this issue and finds this thread ..
As far as I have seen (< 5.0), communication with the network daemon, netd, is done through unix-domain socket IPC on /dev/socket/netd. The commands are of the form:
Code:
interface setcfg [iface name] [options]
Where 'options' includes 'up' and 'down', among others. I have not verified this, but you may be able to do this from the console -- see 'netcfg'. As far as the specific command to do what you are requesting, I would either pull the netcfg executable into IDA or start by looking at the WifiStateMachine. The state machine set sets this option at line 2092 in the source:
Code:
mNwService.setInterfaceIpv6PrivacyExtensions(mInterfaceName, true);
Additionally, you could just pull in the apk for the WifiStateMachine and modify the smali to send false, rather than true, at the line above and you'll have your permanent disable. For this, see /system/framework/*.apk, or equivalent. The WSM implementation should be there somewhere.
-----------
From the source you posted, I found this too ..
Code:
"Usage: interface ipv6privacyextensions <interface> <enable|disable>"
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
chairshot215 said:
Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.
Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.
Click to expand...
Click to collapse
to remove force encryption you need to change "forceencrypt" to "encryptable" in the fstab for userdata. This will not automagically decrypt you, so if you flashed factory images, you will be encrypted again. You will need to format data in TWRP to decrypt again.
I just pushed my anykernel to Github so could post but is pretty much what I had done. what I had done was working after either format data or performing a factory reset with 5.1.1. Starting to think maybe my factory image flash had gone wrong. Could just be a change I am not aware of but did not see the optimizing apps screen after wiping. What I had essentially done is after flashing factory image rebooted bootloader and before booting the first time flashed TWRP installed my Kernel, flashed SuperSu 5.1 and then did a full cache and data wipe.
Admittedly with anykernel I had started by downloading another Kernel, forget which one and then removed or adding what I believed should for my Kernel. So far besides the little encryption issue seems to be working out OK. Trying to keep the Kernel as effective as possible with the fewest possible trade off’s. Not much original work in the sense a lot has already been done but have done lots of testing for efficiency.
Anykernel
https://github.com/Starship-Android/anykernel
chairshot215 said:
Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.
Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.
Click to expand...
Click to collapse
buckmarble said:
https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b
Done in kernel
Click to expand...
Click to collapse
That is actually a *really bad hack*, since it disables selinux rather than manipulating the policy in an appropriate manner to make root usage possible.
The correct changes are actually *outside* of the kernel itself, in the sepolicy file in the ramdisk.
That sepolicy file is generated based primarily on what is in these repositories;
https://android.googlesource.com/platform/external/sepolicy/
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/
You see, there are some interesting commits, like this; https://android.googlesource.com/pl...243e5cf4f8898b7acedc24efd58fdcd163e3048^!/#F0
What that one does, is it tells selinux to never allow the sepolicy to be reloaded from the system_server context.
Or this one here, which does the same for the init context;
https://android.googlesource.com/pl...cy/+/6d0e9c8f4ee4f326b2c2851fa2851193fec33a4e
But note: partially reverted here;
https://android.googlesource.com/pl...abd409af0e7d7fb908e5f04fa1ed946e2996dce^!/#F0
That partial reversion actually provides a very useful HINT about it;
# Note: this requires the following allow rule
# allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
In other words, add that line to this file;
https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/init.te
Then *init* will re-gain the ability to change and reload selinux policies.
HOWEVER, instead of doing that, you might consider going a little further, by enabling THIS in a sortof-user-build;
https://android.googlesource.com/platform/external/sepolicy/+/master/su.te
... and adding domain_auto_trans from untrusted_app to su, and various other adjustments/tweaks.
I think that there is a neverallow rule in there somewhere that will complain if you make that change, so you'll have to kill the neverallow rule... yep, app domain:
https://android.googlesource.com/platform/external/sepolicy/+/master/app.te#286
**note: a neverallow rule is NOT a runtime enforcement directive. selinux defaults to block until a positive allow rule is created. The neverallow rules are used to annoy you when you try to build an sepolicy from source that violates something.
What *I* would do first, is fix that neverallow rule in app, add the auto-transition to su, and run a make bootimg for *USERDEBUG*. You probably should also edit the fstab a bit while you are at it to kill the "verify" parameter from /system, and swap the "forceencrypt" to "encryptable" for /data.
ALL of the changes (besides removing the neverallow rule) can be made in the shamu device tree.
This should produce a boot.img that relaxes selinux a bit to allow su. And from there, the su binary can be root.root/6755, WITH the file context set to su_exec, and you should have root back.... note: su daemon should *NOT* be required with these changes. In fact, you could even proof of concept using "cp /system/bin/sh /system/bin/su; chown root.root /system/bin/su; chmod 6755 /system/bin/su; chcon su_exec /system/bin/su" <-- you will have to look more at the chcon first parameter though, I haven't actually had to use it though, so I'm not entirely sure of what it expects as input. Note the boldness of "proof of concept"... it would be very... unsafe... to actually keep it like that on any device that you actually need to trust.
phhusson's new fork of superuser *should* be able to handle the job, with only minor adjustments to su.c's su_main() function where it is deciding to run connect_daemon() or su_main_nodaemon(). It would need to run su_main_nodaemon() with these changes.
So I've actually been working on this myself, since it is impossible to trust chainfire or his new employer (who is systematically buying up ALL of the root provisioning software for Android), and I have come up with this as an interim step;
Code:
diff --git a/app.te b/app.te
index 40de074..98bb663 100644
--- a/app.te
+++ b/app.te
@@ -283,7 +283,7 @@ neverallow appdomain { domain -appdomain }:process
# Transition to a non-app domain.
# Exception for the shell domain and the su domain, can transition to runas,
# etc.
-neverallow { appdomain -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
+neverallow { appdomain -untrusted_app -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
{ transition dyntransition };
# Write to rootfs.
diff --git a/domain.te b/domain.te
index 0f6c6da..b1d7c41 100644
--- a/domain.te
+++ b/domain.te
@@ -396,7 +396,7 @@ neverallow domain { file_type fs_type dev_type }:{ lnk_file fifo_file sock_file
# Nobody should be able to execute su on user builds.
# On userdebug/eng builds, only dumpstate, shell, and
# su itself execute su.
-neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
+neverallow { domain -init -untrusted_app userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
# Do not allow the introduction of new execmod rules. Text relocations
# and modification of executable pages are unsafe.
diff --git a/init.te b/init.te
index 41eafe2..e7dd87a 100644
--- a/init.te
+++ b/init.te
@@ -123,7 +123,7 @@ allow init security_file:dir { create setattr };
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
-# allow init kernel:security load_policy;
+allow init kernel:security load_policy;
# which can be configured on a device-by-device basis if needed.
r_dir_file(init, security_file)
@@ -283,4 +283,5 @@ neverallow init shell_data_file:lnk_file read;
neverallow init app_data_file:lnk_file read;
# init should never execute a program without changing to another domain.
-neverallow init { file_type fs_type }:file execute_no_trans;
+allow init { file_type fs_type }:file execute_no_trans;
+allow init kernel:security read_policy;
diff --git a/keystore.te b/keystore.te
index 83a0e85..d742d30 100644
--- a/keystore.te
+++ b/keystore.te
@@ -24,7 +24,7 @@ selinux_check_access(keystore)
###
neverallow { domain -keystore } keystore_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -keystore } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -keystore -init } keystore_data_file:dir *;
neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set *;
diff --git a/su.te b/su.te
index d4a488b..1d1f6da 100644
--- a/su.te
+++ b/su.te
@@ -7,6 +7,7 @@ userdebug_or_eng(`
# wrapped to ensure that it does not exist at all on -user builds.
type su, domain, mlstrustedsubject;
domain_auto_trans(shell, su_exec, su)
+ domain_auto_trans(untrusted_app, su_exec, su)
# Allow dumpstate to call su on userdebug / eng builds to collect
# additional information.
diff --git a/vold.te b/vold.te
index b22436f..fa1a879 100644
--- a/vold.te
+++ b/vold.te
@@ -164,7 +164,7 @@ allow vold self:capability sys_chroot;
allow vold storage_file:dir mounton;
neverallow { domain -vold } vold_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -vold } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -vold -init } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow { domain -vold -init } vold_data_file:dir *;
neverallow { domain -vold -init } vold_data_file:notdevfile_class_set *;
neverallow { domain -vold -init } restorecon_prop:property_service set;
Some of those are what reverse engineering I've managed to accomplish on the policy changes required for supersu, and some of them are working towards a better root control infrastructure.
In any case, if you patch platform/external/sepolicy with that, then run a "make bootimage", it *WILL* actually work with supersu.
** note: make sure that you repo init against the android-6.0.0_r1 release branch if you want it to actually be compatible with factory builds. Master has a LOT of MAJOR changes since then and it does not work.
Also note: don't forget to patch platform/device/moto/shamu/fstab.shamu to kill the verify and optionally forceencrypt parameters.
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
doitright said:
I'm just going to leave these two links right here....
https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser
That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!
Take THAT Coding Code Mobile Technology LLC!!!!!
And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.
Click to expand...
Click to collapse
Thanks I have been bed ridden for a bit but will look over all these things. In short my last build I first flashed chainfires boot.img and rooted before flashing my Kernel. Was able to do this without putting my Kernel into permissive mode. Had also unpacked the chainfire boot.img and used a few things in my boot image and used Meld and made a few other edits based on chainfires boot.img. Still having an issue with encryption being forced that just has me baffled. Was otherwise a temporary quick fix for not having to put the Kernel into permissive mode.
Definitely appreciate all the feedback and am learning allot so thanks for that everyone.
Otherwise the Encryption is driving me mentally insane. Like straitjacket throwing myself around a small room with rubber walls and a door with a slot that keeps opening with a tray of drugs and food sliding in insane. It has become so frustrating.
this is the fstab I am using and see know issue. Have also tried Despair, Vortex and the fed_patcher patch not to mention Chainfires Kernel for Root and no matter how many times I wipe data or factory reset it is always encrypted. If it was not knowing the encryption is done via software would swear something is wrong with the phone. Have also changed up TWRP 3 times as noticed I no loner see updating apps but that is also the same in that encription is still forced
https://github.com/Chairshot215/anykernel/blob/master/ramdisk/fstab.shamu
The problem you are running into, is that recovery doesn't actually *format* the userdata partition, which means that a factory reset from recovery won't *remove* the encryption. The reason it doesn't format is to prevent the deletion of /data/media directory, which gets mapped to /sdcard.
What you need to do, is reboot to bootloader, and run "fastboot format userdata".
If you aren't permissive, then the big thing you must have taken from chainfire's boot.img, is the sepolicy file. He only actually changed two files; sepolicy and fstab.shamu.
The thing to be aware of, though, is that his supersu, despite running selinux enforcing, is actually putting a lot of domains into permissive. When you go through your kernel audit log, you should pay attention to the end of the audit log where it says "permissive=1" or "permissive=0". You will find a lot of "permissive=1". Using *my* sepolicy, which is NOT compatible with his supersu, you will find that ALL domains remain enforcing, yet we aren't increasing the authority of any domain besides the "su" domain, AND, there will actually be far fewer denials against root/su. On top of that, I actually block the su domain from messing with kernel security. In other words, we do NOT allow the su domain to change selinux to permissive, OR to reload the policy. Both of those ARE permitted in chainfire supersu, which is incredibly dangerous, given how root is typically used on Android.
To put that into perspective, the ability to change the enforcement status or reload the policy, makes it possible for a malicious application to modify the boot.img to disable dmverity on the system partition, and compromise the system partition. My approach makes it possible to maintain the integrity of the boot partition and therefore maintain dmverity on the system partition, while providing root access. This makes unauthorized changes to the system partition immediately obvious and ineffective, since dmverity will refuse to read changed data, instead returning an i/o error.
The verity keys are actually stored on the boot.img, which means that it is still possible to make *intentional* changes to the system partition (through regenerating the key), and prevent unauthorized changes.
I've been considering adding a new domain to the effect of "su_sensitive" that will enforce strong password input for every authorization request in order to grant kernel security permission, but it remains to be seen if this would even be helpful to anyone.
How do you even edit a kernel? If you could explain, please do so.